Re: [PATCH RFC v4 00/25] fs,kthread: start all kthreads in nullfs

[Askar Safin <safinaskar@gmail.com>]

Christian Brauner <brauner@kernel.org>:
> We now also warn and notice when pid 1 simply stops sharing filesystem
> state with us, i.e., abandons it's userspace_init_fs.
> 
> On older kernels if PID 1 unshared its filesystem state with us the
> kernel simply used the stale fs_struct state implicitly pinning
> anything that PID 1 had last used. Even if PID 1 might've moved on to
> some completely different fs_struct state and might've even unmounted
> the old root.
> 
> This has hilarious consequences: Think continuing to dump coredump
> state into an implicitly pinned directory somewhere. Calling random
> binaries in the old rootfs via usermodehelpers.
> 
> Be aggressive about this: We simply reject operating on stale
> fs_struct state by reverting userspace_init_fs to nullfs. Every kworker
> that does lookups after this point will fail. Every usermodehelper call
> will fail. This is a lot stronger but I wouldn't know what it means for
> pid 1 to simply stop sharing its fs state with the kernel. Clearly it
> wanted to separate so cut all ties.

Your approach means that you introduced new degraded system state:
"PID 1 unshared its fs_struct, so we switched all kernel threads to nullfs".

I don't like this. If PID 1 tries to unshare its fs_struct, then, please,
just do nothing and return error to userspace.

(I already said this in one of previous threads about this. It seems
you missed this, so I'm saying this again.)

-- 
Askar Safin