Re: [PATCH RFC v2 15/23] fs: add real_fs to track task's actual fs_struct

[Christian Brauner]

On Tue, Mar 10, 2026 at 12:29:28PM +0100, Christian Brauner wrote:
> On Mon, Mar 09, 2026 at 04:14:57PM +0100, Jann Horn wrote:
> > On Fri, Mar 6, 2026 at 12:31 AM Christian Brauner <brauner@xxxxxxxxxx> wrote:
> > > Add a real_fs field to task_struct that always mirrors the fs field.
> > > This lays the groundwork for distinguishing between a task's permanent
> > > fs_struct and one that is temporarily overridden via scoped_with_init_fs().
> > >
> > > When a kthread temporarily overrides current->fs for path lookup, we
> > > need to know the original fs_struct for operations like exit_fs() and
> > > unshare_fs_struct() that must operate on the real, permanent fs.
> > 
> > Note that there are remote accesses to ->fs from procfs, including
> > (idk if there are more, I didn't look closely):
> > 
> >  - mounts_open_common
> >  - get_task_root
> >  - proc_cwd_link
> > 
> > These expect that task_lock() keeps the task_struct::fs pointer
> > stable, and I don't see anything that prevents them operating on
> > kthreads.
> > 
> > You should probably ensure that remote accesses to task_struct::fs all
> > use task_struct::real_fs, just like how there are no remote accesses
> > to task_struct::cred - that makes logical sense since when userspace
> > queries a task's file system root/cwd/mounts, what the task is
> > currently doing probably shouldn't affect the result.
> > 
> > Then you could also change the locking rules such that task_struct::fs
> > has no locking while task_lock() protects modifications of, and remote
> > access to, task_struct::real_fs.
> 
> Yes, I have included those changes in the new revision I haven't yet sent out. :)

- umask access in task_state()