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

Steve Grubb sgrubb at redhat.com
Thu Dec 3 13:31:10 UTC 2020


On Wednesday, December 2, 2020 11:12:31 PM EST Paul Moore wrote:
> On Wed, Dec 2, 2020 at 10:52 PM Steve Grubb <sgrubb at redhat.com> wrote:
> > Hello Paul,
> 
> Steve.
> 
> > On Thursday, July 2, 2020 4:42:13 PM EST Paul Moore wrote:
> > > > #define AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT     0x00000001
> > > > #define AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME 0x00000002
> > > > @@ -348,6 +349,7 @@ enum {
> > > > #define AUDIT_FEATURE_BITMAP_SESSIONID_FILTER  0x00000010
> > > > #define AUDIT_FEATURE_BITMAP_LOST_RESET                0x00000020
> > > > #define AUDIT_FEATURE_BITMAP_FILTER_FS         0x00000040
> > > > +#define AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_SUM  0x00000080
> > > 
> > > In an effort not to exhaust the feature bitmap too quickly, I've been
> > > restricting it to only those features that would cause breakage with
> > > userspace.  I haven't looked closely at Steve's userspace in quite a
> > > while, but I'm guessing it can key off the structure size and doesn't
> > > need this entry in the bitmap, right?  Let me rephrase, if userspace
> > > needs to key off anything, it *should* key off the structure size and
> > > not a new flag in the bitmask
> > > 
> > > Also, I'm assuming that older userspace doesn't blow-up if it sees the
> > > larger structure size?  That's even more important.
> > 
> > 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.

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?

-Steve





More information about the Linux-audit mailing list