[GIT PULL] audit/audit-pr-20260410

[GIT PULL] audit/audit-pr-20260410

[Paul Moore]

Linus,

We've only got a few audit patches for the v7.1 merge window, the
highlights are below:

- Improved handling of unknown status requests from userspace

The current kernel code ignores unknown/unused request bits sent from
userspace and returns an error code based on the results of the request(s)
it does understand.  The patch from Ricardo fixes this so that unknown
requests return an -EINVAL to userspace, making compatibility a bit
easier moving forward.

- A number of small style and formatting cleanups

Paul

--
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:

  Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
    tags/audit-pr-20260410

for you to fetch changes up to 360160f75592bdc85edba8fe78fb20d90924c7e8:

  audit: handle unknown status requests in audit_receive_msg()
    (2026-03-10 15:22:43 -0400)

----------------------------------------------------------------
audit/stable-7.1 PR 20260410
----------------------------------------------------------------

Ricardo Robaina (4):
      audit: fix whitespace alignment in include/uapi/linux/audit.h
      audit: remove redundant initialization of static variables to 0
      audit: fix coding style issues
      audit: handle unknown status requests in audit_receive_msg()

 include/linux/audit.h      |    9 +++++++++
 include/uapi/linux/audit.h |    8 ++++----
 kernel/audit.c             |    8 +++++---
 kernel/auditfilter.c       |    3 +--
 lib/audit.c                |    2 +-
 5 files changed, 20 insertions(+), 10 deletions(-)

--
paul-moore.com

Re: [GIT PULL] audit/audit-pr-20260410

[Linus Torvalds]

On Fri, 10 Apr 2026 at 16:26, Paul Moore <paul@paul-moore.com> wrote:
>
> We've only got a few audit patches for the v7.1 merge window, the
> highlights are below:

Pulled. However, can I ask you to take a look at my reply to one of
the vfs pulls, which was actually triggered by audit overhead?

It's entirely unrelated to this particular audit pull, but maybe you
have comments? See

    https://lore.kernel.org/all/CAHk-=wiW53j3vmc1Y58-E_8jUBJtjgAVxDRt+r-w3WPQN+Zm5w@mail.gmail.com/

and it's really all about that current "get_fs_pwd()" in
audit_alloc_name(), and the cache contention it causes when lots of
processes share the same pwd and you get everybody just updating the
path refcounts.

Would it be reasonable to do something along the lines I suggest,
where instead of getting that fairly "global" path refcount, instead
get a reference (with some way to do a copy-on-write break on it) to
'struct fs_struct' instead? No, we don't have that infrastructure (but
it doesn't seem _hugely_ complicated - famous last words), and yes, in
a heavily threaded app you'd still have potentially lots of threads
sharing a 'struct fs_struct', but at least that thing is local to the
process, so it's not shared beyond that.

And no, I don't expect that you'd actually start being interested in
the current root in auditing, but from a bigger VFS perspective, root
and pwd really are just two instances of the exact same thing and I
despise that spull that makes them different at a VFS level.

                  Linus

Re: [GIT PULL] audit/audit-pr-20260410

[pr-tracker-bot]

The pull request you sent on Fri, 10 Apr 2026 19:26:18 -0400:

> https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git tags/audit-pr-20260410

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/de639344bbe962985e3de22cc8d1388b016c1e54

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] audit/audit-pr-20260410

[Paul Moore]

On Mon, Apr 13, 2026 at 6:13 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, 10 Apr 2026 at 16:26, Paul Moore <paul@paul-moore.com> wrote:
> >
> > We've only got a few audit patches for the v7.1 merge window, the
> > highlights are below:
>
> Pulled. However, can I ask you to take a look at my reply to one of
> the vfs pulls, which was actually triggered by audit overhead?
>
> It's entirely unrelated to this particular audit pull, but maybe you
> have comments? See
>
>     https://lore.kernel.org/all/CAHk-=wiW53j3vmc1Y58-E_8jUBJtjgAVxDRt+r-w3WPQN+Zm5w@mail.gmail.com/
>
> and it's really all about that current "get_fs_pwd()" in
> audit_alloc_name(), and the cache contention it causes when lots of
> processes share the same pwd and you get everybody just updating the
> path refcounts.
>
> Would it be reasonable to do something along the lines I suggest,
> where instead of getting that fairly "global" path refcount, instead
> get a reference (with some way to do a copy-on-write break on it) to
> 'struct fs_struct' instead? No, we don't have that infrastructure (but
> it doesn't seem _hugely_ complicated - famous last words), and yes, in
> a heavily threaded app you'd still have potentially lots of threads
> sharing a 'struct fs_struct', but at least that thing is local to the
> process, so it's not shared beyond that.
>
> And no, I don't expect that you'd actually start being interested in
> the current root in auditing, but from a bigger VFS perspective, root
> and pwd really are just two instances of the exact same thing and I
> despise that spull that makes them different at a VFS level.

It seems reasonable. Perhaps some gotchas will pop up as someone
writes the code, but it's worth a shot as far as I'm concerned.

I say this a lot, and frankly, it should be evident to anyone who has
looked at the code: the audit stuff is pretty garbage.  It mostly
works and solves real user problems, so there is that, but the design
is awful and the implementation is worse.  I have been off-and-on
working on a replacement for some time, but most of the time I only
get a day or so to work on it before another fire demands attention;
progress is glacially slow.  That said, if someone wants to send me a
patch to convert audit to work off of fs_struct I'd happily take a
closer look and merge it if all is well.

-- 
paul-moore.com