Re: [RFC PATCH 1/3] audit: remove arch_f pointer from struct audit_krule

[Paul Moore]

On Mon, Nov 26, 2018 at 2:21 PM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote:
> On 2018-11-26 11:37, Paul Moore wrote:
> > On Sun, Nov 25, 2018 at 12:11 PM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote:
> > > On 2018-02-15 15:42, Paul Moore wrote:
> > > > On Mon, Feb 12, 2018 at 7:29 AM, Richard Guy Briggs <rgb@xxxxxxxxxx> wrote:
> > > > > The arch_f pointer was added to the struct audit_krule in commit:
> > > > > e54dc2431d740a79a6bd013babade99d71b1714f ("audit signal recipients")
> > > > >
> > > > > This is only used on addition and deletion of rules which isn't time
> > > > > critical and the arch field is likely to be one of the first fields,
> > > > > easily found iterating over the field type.  This isn't worth the
> > > > > additional complexity and storage.  Delete the field.
> > > > >
> > > > > Signed-off-by: Richard Guy Briggs <rgb@xxxxxxxxxx>
> > > > > ---
> > > > >  include/linux/audit.h |  1 -
> > > > >  kernel/auditfilter.c  | 12 ++++++++----
> > > > >  2 files changed, 8 insertions(+), 5 deletions(-)
> > > >
> > > > I haven't decided if I like the removal of arch_f or not, but I think
> > > > I might know where your oops/panic is coming from, thoughts below ...
> > >
> > > Have you decided yet if you like the removal of the arch_f pointer or
> > > not?  An updated v2 was provided the following day:
> > >         https://www.redhat.com/archives/linux-audit/2018-February/msg00059.html
> >
> > I still think I'd like to keep it as-is for now.
>
> Can you explain why you'd prefer to keep it as-is for now?  Is there a
> factor I'm not aware of that might make it acceptable later?  arch_f
> appears to make the code noisier than needed and use extra memory that
> is a convenience at best only when adding or deleting rules.

Personal preference for the existing approach, status quo, gut
feeling, etc.  Some things are simply judgement calls.

Please stop trying to find a four page, black-and-white explanation
reason for every single patch that is rejected; it is getting very
tiring.  I typically provide reasons when I don't merge a patch, and
often on these smaller, trade-off patches it falls into the "judgement
call" category and there simply isn't a detailed response to be given.

-- 
paul moore
www.paul-moore.com