From: Al Viro <viro@zeniv.linux.org.uk>
To: Waiman Long <llong@redhat.com>
Cc: Paul Moore <paul@paul-moore.com>, Eric Paris <eparis@redhat.com>,
Christian Brauner <brauner@kernel.org>,
linux-kernel@vger.kernel.org, audit@vger.kernel.org,
Richard Guy Briggs <rgb@redhat.com>,
Ricardo Robaina <rrobaina@redhat.com>
Subject: Re: [PATCH v2] audit: Avoid excessive dput/dget in audit_context setup and reset paths
Date: Tue, 3 Feb 2026 23:26:34 +0000 [thread overview]
Message-ID: <20260203232634.GJ3183987@ZenIV> (raw)
In-Reply-To: <20260203215002.GI3183987@ZenIV>
On Tue, Feb 03, 2026 at 09:50:02PM +0000, Al Viro wrote:
> On Tue, Feb 03, 2026 at 03:32:04PM -0500, Waiman Long wrote:
>
> > That is actually a concern that I have at the back of my mind. I can modify
> > the patch to cache only the dentry and do get/put the mount every time which
> > is much cheaper as it is a percpu counter. In that way, a chdir(2) followed
> > by a umount(2) shouldn't cause a -EBUSY. Right?
>
> Quite - it will just retain a reference to dentry, with filesystem shutdown
> being very unhappy about somebody retaining references to objects on the
> filesystem about to be taken out...
Sarcasm aside, I wonder if we could do the following trick:
* a new primitive for "grab or borrow pwd", similar to what fdget()
does for struct file. If current->fs is shared, do what we do now and return
true; otherwise just copy the contents of current->fs->pwd return false.
* paired primitive that would take a boolean + struct path * and
do path_put() if boolean is true.
* syscalls that might alter ->fs, ->fs->pwd or add extra references to
->fs would start with grabbing an extra ref on entry and drop it in the end;
that would make that primitive safe to use there.
* audit using that thing and storing the result along with the copy
of pwd; on the way out it would use the "put unless borrowed" primitive.
Might or might not be useful - hard to tell without knowing the job mix of those
audit-afflicted production systems.
I'll try to put something along those lines together...
next prev parent reply other threads:[~2026-02-03 23:24 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 19:44 [PATCH v2] audit: Avoid excessive dput/dget in audit_context setup and reset paths Waiman Long
2026-02-03 19:59 ` Al Viro
2026-02-03 20:18 ` Waiman Long
2026-02-03 20:05 ` Al Viro
2026-02-03 20:32 ` Waiman Long
2026-02-03 21:50 ` Al Viro
2026-02-03 23:26 ` Al Viro [this message]
2026-02-04 4:21 ` Waiman Long
2026-02-04 6:26 ` Al Viro
2026-02-04 18:16 ` Waiman Long
2026-02-04 20:18 ` Al Viro
2026-02-05 3:03 ` Waiman Long
2026-02-05 4:45 ` Waiman Long
2026-02-05 23:53 ` Al Viro
2026-02-06 1:20 ` Waiman Long
2026-02-06 4:11 ` Waiman Long
2026-02-06 4:19 ` Waiman Long
2026-02-06 5:22 ` Al Viro
2026-02-06 6:31 ` Al Viro
2026-02-06 6:38 ` Al Viro
2026-02-06 7:13 ` Al Viro
2026-02-06 19:16 ` Waiman Long
2026-02-06 20:04 ` Waiman Long
2026-02-06 20:38 ` Al Viro
2026-02-07 8:25 ` [PATCH][RFC] bug in unshare(2) failure recovery Al Viro
2026-02-07 23:06 ` Waiman Long
2026-02-17 12:49 ` Christian Brauner
2026-02-17 12:49 ` Christian Brauner
2026-02-06 20:29 ` [PATCH v2] audit: Avoid excessive dput/dget in audit_context setup and reset paths Al Viro
2026-02-06 20:58 ` setns(2) vs. pivot_root(2) (was Re: [PATCH v2] audit: Avoid excessive dput/dget in audit_context setup and reset paths) Al Viro
2026-02-06 21:09 ` Al Viro
2026-02-17 13:12 ` Christian Brauner
2026-02-06 8:15 ` [PATCH v2] audit: Avoid excessive dput/dget in audit_context setup and reset paths Al Viro
2026-02-05 5:22 ` Al Viro
2026-02-05 13:59 ` Waiman Long
2026-02-05 17:53 ` Mateusz Guzik
2026-02-17 13:33 ` Christian Brauner
2026-02-17 13:44 ` Mateusz Guzik
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=20260203232634.GJ3183987@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=audit@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=eparis@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=llong@redhat.com \
--cc=paul@paul-moore.com \
--cc=rgb@redhat.com \
--cc=rrobaina@redhat.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.