On Tue, Feb 17, 2026 at 2:33 PM Christian Brauner <[email protected]> wrote: > > On Thu, Feb 05, 2026 at 06:53:34PM +0100, Mateusz Guzik wrote: > > On Thu, Feb 5, 2026 at 6:20 AM Al Viro <[email protected]> wrote: > > > Mateusz: *is* there a measurable effect? Because if there isn't, I'm > > > very tempted to simply revert that thing. "Churn of adding fs_struct.h > > > as needed" is not the problem - try "exposing the object internals to > > > far larger subset of the kernel". We had interesting bugs with weird > > > shit deciding to poke in there, locking and refcounting be damned. > > > > This one I did not bother benchmarking as it is an obvious change -- > > read a var directly instead of going through a func call. > > > > If this is causing trouble then it definitely needs to be reverted, > > but any woes only speak to the mess in the header files. > > Any reason this isn't just stealing the cred.h trick? > > diff --git a/include/linux/fs_struct.h b/include/linux/fs_struct.h > index 0070764b790a..e8b8d073f9e0 100644 > --- a/include/linux/fs_struct.h > +++ b/include/linux/fs_struct.h > @@ -2,11 +2,12 @@ > #ifndef _LINUX_FS_STRUCT_H > #define _LINUX_FS_STRUCT_H > > -#include <linux/sched.h> > #include <linux/path.h> > #include <linux/spinlock.h> > #include <linux/seqlock.h> > > +struct task_struct; > + > struct fs_struct { > int users; > seqlock_t seq; > @@ -42,9 +43,6 @@ static inline void get_fs_pwd(struct fs_struct *fs, struct > path *pwd) > > extern bool current_chrooted(void); > > -static inline int current_umask(void) > -{ > - return current->fs->umask; > -} > +#define current_umask() (current->fs->umask) > > #endif /* _LINUX_FS_STRUCT_H */ >
This depends on the users having task_struct already provided, which sooner or later will give someone a build breakage when they work on a new patch, but perhaps that's just a minor inconvenience and is not worth worrying about. That said, if the above is no considered a factor, I'm definitely not going to protest.
