From: Matt Bobrowski <matt@bobrowski.net>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: bpf@vger.kernel.org, Daniel Borkmann <daniel@iogearbox.net>,
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>,
Christian Brauner <brauner@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>, 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: Wed, 21 Oct 2026 21:58:09 +1100 [thread overview]
Message-ID: <atiawbBo6WRPA6QA@lima-development> (raw)
In-Reply-To: <DM9VJTFJGVXB.3GH9LO3NGV5PO@gmail.com>
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 keeps d_path()'s semantics intact, keeps pipe:[N] and socket:[N]
working at exit, and turns the oops into an error for every caller,
including the ext4 open path you mentioned. Nothing that works today
changes behaviour; only calls that currently oops are affected. Callers
that want a name in that state then have to choose one explicitly, which
I take to be Al's point.
For BPF, that choice could be a new BPF kfunc wrapping
d_absolute_path(), so programs can pick whichever semantics they actually
want, and file_release programs that need a name at exit get one whose
format doesn't depend on how far the task got through do_exit(). I'd
prefer that over silently falling back to d_absolute_path() inside
bpf_path_d_path(), which would return chroot-relative names before
exit_fs() and absolute ones after, and still wouldn't help pipes and
sockets since d_absolute_path() rejects internal mounts.
Al, would a check like the above in d_path() be acceptable to you?
> diff --git a/fs/d_path.c b/fs/d_path.c
> index c253090..ea49d33 100644
> --- a/fs/d_path.c
> +++ b/fs/d_path.c
> @@ -265,7 +265,7 @@ static void get_fs_root_rcu(struct fs_struct *fs, struct path *root)
> char *d_path(const struct path *path, char *buf, int buflen)
> {
> DECLARE_BUFFER(b, buf, buflen);
> - struct path root;
> + struct path root = {};
>
> /*
> * We have various synthetic filesystems that never get mounted. On
> @@ -284,7 +284,9 @@ char *d_path(const struct path *path, char *buf, int buflen)
> return path->dentry->d_op->d_dname(path->dentry, buf, buflen);
>
> rcu_read_lock();
> - get_fs_root_rcu(current->fs, &root);
> + /* Past exit_fs() there is no root to stop at, go up to the global one. */
> + if (current->fs)
> + get_fs_root_rcu(current->fs, &root);
> if (unlikely(d_unlinked(path->dentry)))
> prepend(&b, " (deleted)", 11);
> else
>
> pw-bot: cr
next prev parent reply other threads:[~2026-10-21 10:58 UTC|newest]
Thread overview: 8+ 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 [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
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=atiawbBo6WRPA6QA@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.