public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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