From: Christian Brauner <brauner@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Waiman Long <longman@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL 05/12 for v7.1] vfs fs_struct
Date: Tue, 14 Apr 2026 11:52:24 +0200 [thread overview]
Message-ID: <20260414-garen-eckwerte-62bd3b06005a@brauner> (raw)
In-Reply-To: <CAHk-=wiW53j3vmc1Y58-E_8jUBJtjgAVxDRt+r-w3WPQN+Zm5w@mail.gmail.com>
On Mon, Apr 13, 2026 at 12:18:16PM -0700, Linus Torvalds wrote:
> On Fri, 10 Apr 2026 at 08:18, Christian Brauner <brauner@kernel.org> wrote:
> >
> > Avoid excessive dput/dget in audit_context setup and reset paths
>
> I really don't like this one, and I'm going to at least delay pulling it.
I don't like it either.
> Because this really feels wrong to me. It feels like a hack. Just
It is. I commented on that explicitly when the series was proposed.
> looking at some of the paths that get modified, we have that
> copy_fs_struct, which does
>
> path_get(&fs->root);
>
> to increment the root, and then the very next line ends up being
>
> get_fs_pwd_pool_locked(old, &fs->pwd);
>
> that copies the pwd very differently.
>
> And the only reason 'pwd' is different is because the audit code
> treats pwd and root differently.
>
> And that, in turn, is because the audit code is just historical and
> broken, and can't deal with chroot environments.
>
> The pwd and root paths are two sides of the same coin, and any code
> that treats them this differently is *wrong*.
>
> So this basically takes a audit mistake, and makes that mistake
> visible to non-audit users.
>
> I absolutely hate it.
>
> I'm going to think about this more, and maybe I'll end up saying "it's
> still ugly, but whatever, I'll pull it anyway".
>
> But right now I'm going "there HAS to be a better way".
>
> And maybe you can convince me this hackery is the right thing, but it
It isn't and I'm not going to try.
> really is rubbing me the wrong way entirely.
I'm sorry I can't offer more than agreement with you right now. The only
reason I considered it was that my appetetite for audit internals is
very very low but tbh that shouldn't have led me to accept the
hackishness. So again, no long-winded argument from me here... I droped
this from the other pr. The CI is still running then I'll resend.
next prev parent reply other threads:[~2026-04-14 9:52 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-10 15:15 [GIT PULL 00/12 for v7.1] v7.1 Christian Brauner
2026-04-10 15:16 ` [GIT PULL 01/12 for v7.1] vfs writeback Christian Brauner
2026-04-13 17:53 ` pr-tracker-bot
2026-04-10 15:16 ` [GIT PULL 02/12 for v7.1] vfs xattr Christian Brauner
2026-04-13 17:53 ` pr-tracker-bot
2026-04-10 15:16 ` [GIT PULL 03/12 for v7.1] vfs directory Christian Brauner
2026-04-13 17:53 ` pr-tracker-bot
2026-04-10 15:17 ` [GIT PULL 04/12 for v7.1] vfs integrity Christian Brauner
2026-04-13 17:53 ` pr-tracker-bot
2026-04-10 15:18 ` [GIT PULL 05/12 for v7.1] vfs fs_struct Christian Brauner
2026-04-13 19:18 ` Linus Torvalds
2026-04-14 9:52 ` Christian Brauner [this message]
2026-04-10 15:18 ` [GIT PULL 06/12 for v7.1] vfs kino Christian Brauner
2026-04-13 22:48 ` pr-tracker-bot
2026-04-10 15:19 ` [GIT PULL 07/12 for v7.1] vfs fat Christian Brauner
2026-04-13 22:48 ` pr-tracker-bot
2026-04-10 15:19 ` [GIT PULL 08/12 for v7.1] vfs bh metadata Christian Brauner
2026-04-13 22:48 ` pr-tracker-bot
2026-04-10 15:19 ` [GIT PULL 09/12 for v7.1] namespaces misc Christian Brauner
2026-04-13 22:48 ` pr-tracker-bot
2026-04-10 15:21 ` [GIT PULL 10/12 for v7.1] vfs pidfs Christian Brauner
2026-04-13 22:48 ` pr-tracker-bot
2026-04-10 15:21 ` [GIT PULL 11/12 for v7.1] vfs mount Christian Brauner
2026-04-13 21:17 ` Linus Torvalds
2026-04-14 10:58 ` Christian Brauner
2026-04-15 3:38 ` pr-tracker-bot
2026-04-10 15:23 ` [GIT PULL 12/12 for v7.1] vfs misc Christian Brauner
2026-04-13 22:48 ` pr-tracker-bot
2026-04-14 12:46 ` [GIT PULL for v7.1] kernel misc Christian Brauner
2026-04-15 3:38 ` pr-tracker-bot
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=20260414-garen-eckwerte-62bd3b06005a@brauner \
--to=brauner@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=torvalds@linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox