All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: Paul Moore <paul@paul-moore.com>
Cc: linux-audit@redhat.com
Subject: Re: [PATCH v2] audit: report audit wait metric in audit status reply
Date: Thu, 03 Dec 2020 08:31:10 -0500	[thread overview]
Message-ID: <2565471.mvXUDI8C0e@x2> (raw)
In-Reply-To: <CAHC9VhQzRP6Gyji83MEjQbdZxePLFn2Ai7Zo-Wd0D7MPqQ_Ekw@mail.gmail.com>

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@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


--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit


  parent reply	other threads:[~2020-12-03 13:32 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-01 21:32 [PATCH v2] audit: report audit wait metric in audit status reply Max Englander
2020-07-02 20:42 ` Paul Moore
2020-07-03 21:29   ` Richard Guy Briggs
2020-07-03 22:36     ` Max Englander
2020-07-03 22:31   ` Max Englander
2020-12-03  3:52   ` Steve Grubb
2020-12-03  4:12     ` Paul Moore
2020-12-03 12:37       ` Richard Guy Briggs
2020-12-03 15:37         ` Paul Moore
2020-12-03 23:10           ` Richard Guy Briggs
2020-12-03 23:43             ` Paul Moore
2020-12-03 23:55               ` Steve Grubb
2020-12-04  2:16                 ` Paul Moore
2020-12-04  2:47                   ` Steve Grubb
2020-12-04 20:41                     ` Paul Moore
2020-12-07 21:13                       ` Max Englander
2020-12-07 21:17                         ` Paul Moore
2020-12-07 21:21                         ` Richard Guy Briggs
2020-12-07 21:28                           ` Max Englander
2020-12-07 23:28                             ` Steve Grubb
2020-12-08  1:34                               ` Richard Guy Briggs
2020-12-08  3:34                                 ` Steve Grubb
2020-12-08 13:20                                   ` Richard Guy Briggs
2020-12-08 13:44                                     ` Steve Grubb
2020-12-08 23:08                                 ` Paul Moore
2020-12-03 13:31       ` Steve Grubb [this message]
2020-12-07 19:43   ` Lenny Bruzenak
2020-12-07 21:14     ` Paul Moore
2020-12-03  4:33 ` Joe Wulf
2020-12-07 21:48   ` Max Englander
2020-12-08 16:57 ` Lenny Bruzenak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2565471.mvXUDI8C0e@x2 \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=paul@paul-moore.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.