Re: [PATCH v7 07/12] kernfs: hold kernfs_iattr_rwsem when initializing a new inode

[Jori Koolstra]

> Op 16-10-2026 10:50 EDT schreef Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>:
> 
>  
> On Fri, Oct 16, 2026 at 04:38:01PM +0200, Jori Koolstra wrote:
> > kernfs_refresh_inode() copies the uid, gid, timestamps and nlink of a
> > kernfs_node into its VFS inode. Since commit 9caf69614225 ("kernfs:
> > Introduce separate rwsem to protect inode attributes.") these are
> > protected by kernfs_iattr_rwsem.
> > 
> > kernfs_init_inode() calls kernfs_refresh_inode(), but was not converted.
> > Its callers in turn hold kernfs_rwsem (kernfs_iop_lookup(),
> > kernfs_fill_super()) or no lock at all (__kernfs_fh_to_dentry()),
> > neither of which excludes a concurrent
> > kernfs_setattr()/kernfs_iop_setattr().
> > 
> > Take kernfs_iattr_rwsem for reading around the refresh in
> > kernfs_init_inode(). This nests inside kernfs_rwsem, which matches
> > kernfs_link_sibling() and kernfs_unlink_sibling().
> > 
> > Also, kernfs_get_inode() then does not need to hold kernfs_rwsem, so
> > drop it from kernfs_fill_super().
> 
> Oh, nice, this fixes the issue of kernfs not keeping the inode like we
> talked about at LPC?  Can't argue with this tiny patch, nice work!

No, that part is included in the patch following this one. This is a bit of
preliminary work to fix the locking around kernfs_refresh_inode(). I think the
memory requirement for the allocated inodes is not a blocker (but you judge, since
you told me that's the primary concern here). The inode allocation only happens
for userspace mkdir(2) calls afaict, and then you probably want to do a lookuo
anyway.

I see there's some work by a Meta team on kernfs. Since I'm in that code now
I'll try to review that soon.

Enjoy the weekend!
Jori.

> 
> Reviewed-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>