All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Bobrowski <matt@bobrowski.net>
To: Christian Brauner <brauner@kernel.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	bpf@vger.kernel.org, Daniel Borkmann <daniel@iogearbox.net>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	Jiri Olsa <jolsa@kernel.org>,
	Emil Tsalapatis <emil@etsalapatis.com>,
	Ihor Solodrai <ihor.solodrai@linux.dev>, Jan Kara <jack@suse.cz>,
	linux-fsdevel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH bpf-next 1/2] bpf: fix crash in bpf_path_d_path() for exiting tasks
Date: Fri, 6 Nov 2026 08:03:56 +1100	[thread overview]
Message-ID: <auzvPMnq2vrLaBdB@lima-development> (raw)
In-Reply-To: <20261105-berglandschaft-mitbringen-baufinanzierung-c0542594d218@brauner>

On Thu, Nov 05, 2026 at 04:44:34PM +0100, Christian Brauner wrote:
> On Tue, Oct 27, 2026 at 08:55:57AM +1100, Matt Bobrowski wrote:
> > On Wed, Oct 21, 2026 at 09:58:09PM +1100, Matt Bobrowski wrote:
> > > On Tue, Oct 20, 2026 at 06:24:42PM +0000, Alexei Starovoitov wrote:
> > > > On Tue, Oct 20, 2026 at 03:50 AM Matt Bobrowski <matt@bobrowski.net> wrote:
> > > > > Fix this by returning -EINVAL from bpf_path_d_path() when current->fs
> > > > > is NULL. Only the task itself clears its fs, in exit_fs(), so the check
> > > > > cannot race with that.
> > > > 
> > > > The crash is gone, but so is the path. file_release progs will get
> > > > -EINVAL for every file that a task still has open when it exits.
> > > > 
> > > > It also breaks what works today. The d_dname branch in d_path() returns
> > > > before it looks at current->fs, so at task exit a pipe or a socket
> > > > resolves to "pipe:[123]" now and to -EINVAL with this patch.
> > > > 
> > > > And it's not specific to bpf. The comment in fs/cachefiles/namei.c says
> > > > that current->fs == NULL in do_exit() breaks d_path() called from ext4
> > > > open.
> > > > 
> > > > can we fix it in d_path() instead ?
> > > > With an empty root prepend_path() goes up to the global root, the same
> > > > way d_absolute_path() does. Then the check in bpf_path_d_path() is not
> > > > needed and the selftest can expect the path. A chrooted task gets the
> > > > path from the global root, but it doesn't have a root anymore.
> > > > 
> > > > Something like this (compile tested only):
> > > 
> > > Prior to sending out the fix, I also considered addressing this directly
> > > within d_path(), much like you've proposed here, but decided against
> > > it. d_path()'s contract is to build a pathname relative to the current
> > > root. It does fall back to a root-independent name when the path isn't
> > > reachable from that root, but that fallback still presupposes the caller
> > > has a root to measure against. An exiting task past exit_fs() has no
> > > root, so d_path() has no correct answer to give in that state, and I'm
> > > not convinced we should invent one for it.  That's what
> > > d_absolute_path() is for.
> > > 
> > > You're right that my patch regresses the d_dname case though, since
> > > pipes and sockets resolve today without ever looking at current->fs.
> > > Rather than replicating the d_dname check in bpf_path_d_path(), which
> > > would mean duplicating VFS logic such as the mounted pseudo-inode
> > > special case, I think the cleaner fix is to move the "no root, no
> > > answer" check into d_path() itself, after the d_dname branch:
> > > 
> > > 	if (unlikely(!current->fs))
> > > 		return ERR_PTR(-ENOENT);
> 
> That seems ok albeit fugly.

Yeah, not super nice, I agree...

Anyway, I'll respin this series with what I've proposed above.

  reply	other threads:[~2026-11-05 21:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-20 10:50 [PATCH bpf-next 0/2] bpf: fix crash in bpf_path_d_path() for exiting tasks Matt Bobrowski
2026-10-20 10:50 ` [PATCH bpf-next 1/2] " Matt Bobrowski
2026-10-20 17:36   ` Song Liu
2026-10-20 18:24   ` Alexei Starovoitov
2026-10-20 19:02     ` Al Viro
2026-10-21 10:58     ` Matt Bobrowski
2026-10-26 21:55       ` Matt Bobrowski
2026-11-05 15:44         ` Christian Brauner
2026-11-05 21:03           ` Matt Bobrowski [this message]
2026-10-20 10:50 ` [PATCH bpf-next 2/2] selftests/bpf: test bpf_path_d_path() on a file released at task exit Matt Bobrowski
2026-10-20 17:37   ` Song Liu
     [not found] <20261020102510.96685-1-matt@bobrowski.net>
2026-10-20 10:25 ` [PATCH bpf-next 1/2] bpf: fix crash in bpf_path_d_path() for exiting tasks Matt Bobrowski

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=auzvPMnq2vrLaBdB@lima-development \
    --to=matt@bobrowski.net \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=emil@etsalapatis.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=jack@suse.cz \
    --cc=jolsa@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=memxor@gmail.com \
    --cc=song@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yonghong.song@linux.dev \
    /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.