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 */
