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

[Paul Moore]

On Thu, Dec 3, 2020 at 6:10 PM Richard Guy Briggs <rgb at redhat.com> wrote:
> On 2020-12-03 10:37, Paul Moore wrote:
> > On Thu, Dec 3, 2020 at 7:37 AM Richard Guy Briggs <rgb at redhat.com> wrote:
> > > On 2020-12-02 23:12, Paul Moore wrote:
> > > > On Wed, Dec 2, 2020 at 10:52 PM Steve Grubb <sgrubb at redhat.com> 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 at redhat.com> 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 at redhat.com>
>         AuthorDate: 2014-11-17 15:51:01 -0500
>         Commit:     Paul Moore <pmoore at redhat.com>
>         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.

Let me be blunt - I honestly don't care what Steve's audit userspace
does to detect this.  I've got my own opinion, but Steve's audit
userspace is not my project to manage and I think we've established
over the years that Steve and I have very different views on what
constitutes good design.

-- 
paul moore
www.paul-moore.com