On Wednesday, December 2, 2020 11:12:31 PM EST Paul Moore wrote: > On Wed, Dec 2, 2020 at 10:52 PM Steve Grubb <[email protected]> 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 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
