Re: [PATCH RFC v3 26/26] fs: stop rewriting paths for PF_EXITING | PF_DUMPCORE

[Jann Horn]

On Wed, Mar 11, 2026 at 10:57 PM Christian Brauner <brauner@xxxxxxxxxx> wrote:
> If the task is dead or dumping core stop messing with its fs struct.
> There's no point in doing that. Worst case it'll be stuck in a stale
> path until it calls exit_fs().
>
> Signed-off-by: Christian Brauner <brauner@xxxxxxxxxx>
> ---
>  fs/fs_struct.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/fs/fs_struct.c b/fs/fs_struct.c
> index 2a98cfbedd32..34699f3b6f88 100644
> --- a/fs/fs_struct.c
> +++ b/fs/fs_struct.c
> @@ -61,8 +61,7 @@ void chroot_fs_refs(const struct path *old_root, const struct path *new_root)
>
>         read_lock(&tasklist_lock);
>         for_each_process_thread(g, p) {
> -               /* leave kthreads alone */
> -               if (p->flags & PF_KTHREAD)
> +               if (p->flags & (PF_KTHREAD | PF_EXITING | PF_DUMPCORE))
>                         continue;

If an exiting/dumping task still refers to the old root, that could
prevent unmounting the old root, right? In the case of umount2(...,
MNT_DETACH), it would just delay destroying the old rootfs until the
exiting/dumping task is gone (which hopefully won't take long); in the
case of umount(...), it could cause an error, though I don't know if
anything would do that - I guess that'd be very brittle, and the
pivot_root.2 manpage suggests MNT_DETACH. And pivot_root isn't really
a syscall one would use when anything is concurrently running in the
mount namespace, so this probably shouldn't matter in practice...

So I think this change is probably fine, but I wouldn't say that there
is entirely no point in updating exiting/dumping tasks.