Re: [PATCH v2] audit: report audit wait metric in audit status reply

On 2020-12-03 10:37, Paul Moore wrote: > On Thu, Dec 3, 2020 at 7:37 AM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > > On 2020-12-02 23:12, Paul Moore wrote: > > > On Wed, Dec 2, 2020 at 10:52 PM Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > > > > We need this FEATURE_BITMAP to do anything in userspace. Max's instinct was > > > > right. Anything that changes the user space API needs to have a > > > > FEATURE_BITMAP so that user space can do the right thing. The lack of this is > > > > blocking acceptance of the pull request for the user space piece. > > > > > > I don't believe you need a new bitmap entry in this case, you should > > > be able to examine the size of the reply from the AUDIT_GET request > > > and make a determination from there. > > > > The danger I see is if another feature is added to the audit status and > > that is backported to a distro rather than this one. It would be > > impossible to determine which feature it was from the size alone. > > Keying off specific fields in the kernel should be able to do > > this at build time if I understood correctly. > > ... > > On Thu, Dec 3, 2020 at 8:31 AM Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > > For the upstream kernel, this may be the case. But in the world where people > > backport patches, how do I know that the size is related to this patch and no > > other? > > We've discussed this in the past, and most of you should already know > my answer to this, but I'll repeat my stance on this again. > > My first priority is the upstream kernel, enterprise distribution > kernels are secondary. The upstream kernels do not generally backport > features, backports are limited to fixes. If an individual or a > distribution decides to backport kernel features they are responsible > for making things work; it is not upstream's responsibility to enable, > or support, arbitrary combinations of patches. Any assistance we > provide here is "best effort" and not guaranteed. > > Bringing this back to the case at hand, the feature bitmap is a > limited resource and it is my opinion that we need to limit its use to > only those features which can not be determined through other means; So far there are only seven bits used out of 32, so it does not appear we are in danger of running out anytime soon. It was introduced with commit 0288d7183c41c0192d2963d44590f346f4aee917 Author: Richard Guy Briggs <rgb(a)redhat.com&gt; AuthorDate: 2014-11-17 15:51:01 -0500 Commit: Paul Moore <pmoore(a)redhat.com&gt; CommitDate: 2014-11-17 16:53:51 -0500 ("audit: convert status version to a feature bitmap") It was introduced specifically to enable distributions to selectively backport features. It was converted away from AUDIT_VERSION. There are other ways to detect the presence of backlog_wait_time_actual as I mentioned above.