All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shakeel Butt <shakeel.butt@linux.dev>
To: Jori Koolstra <jkoolstra@xs4all.nl>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	 Tejun Heo <tj@kernel.org>,
	Christian Brauner <christian@brauner.io>,
	 Meta kernel team <kernel-team@meta.com>,
	linux-fsdevel@vger.kernel.org, driver-core@lists.linux.dev,
	 linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] kernfs: allocate inodes and dentry outside kernfs_rwsem
Date: Mon, 19 Oct 2026 16:34:19 -0700	[thread overview]
Message-ID: <ataWrUkD-rqeoFcV@linux.dev> (raw)
In-Reply-To: <atUkrrdfu_ihfmZ8@daedalus>

Hi Jori and thanks a lot for taking a look.

On Sun, Oct 18, 2026 at 10:47:56PM +0200, Jori Koolstra wrote:
> On Fri, Oct 16, 2026 at 03:00:29PM -0700, Shakeel Butt wrote:
[...]
> > +/**
> > + * kernfs_get_inode_locked - get the inode of @kn under kernfs_rwsem
> > + * @sb: super block
> > + * @kn: kernfs_node to get the inode for
> > + * @new: points to an inode from new_inode(@sb), or to %NULL if that failed
> > + *
> > + * The caller allocates *@new before taking kernfs_rwsem, as the allocation
> > + * can stall in memcg reclaim.  If @kn needs a new inode, *@new is used and
> 
> I wouldn't mention memcg here per se, it is not relevant to grasp its
> use. In another series I have implemented almost the same thing (but you
> did it better!).

Ack, will remove memcg here.

> 
> > + * set to %NULL.  Otherwise the caller frees it with iput() after dropping
> > + * the lock.
> > + *
> > + * A new inode is added only with kernfs_rwsem held and @kn active, so
> > + * __kernfs_remove() always finds it to clear i_nlink.
> > + *
> > + * Context: kernfs_rwsem held for read.
> > + *
> > + * Return: the inode, %NULL if @kn is inactive and has no inode, or
> > + * ERR_PTR(-ENOMEM) if @kn needs an inode and *@new is %NULL.
> > + */
> > +struct inode *kernfs_get_inode_locked(struct super_block *sb,
> > +				      struct kernfs_node *kn,
> > +				      struct inode **new)
> 
> I understand this is intended to have some kind of ownership semantics,
> but I must say for such a simple function, I find the contract quite
> complex to check. Do we really need an out parameter here?

Not really. I just used it simply call iput(new) without a check. I can change
it and make it more like inode_insert5() and let caller do check before calling
iput().

> 
[...]
> > @@ -294,7 +298,7 @@ static int kernfs_fill_super(struct super_block *sb, struct kernfs_fs_context *k
> >  {
> >  	struct kernfs_super_info *info = kernfs_info(sb);
> >  	struct kernfs_root *kf_root = kfc->root;
> > -	struct inode *inode;
> > +	struct inode *inode, *new;
> >  	struct dentry *root;
> >  
> >  	info->sb = sb;
> > @@ -314,10 +318,12 @@ static int kernfs_fill_super(struct super_block *sb, struct kernfs_fs_context *k
> >  	sb->s_shrink->seeks = 0;
> >  
> >  	/* get root inode, initialize and unlock it */
> > +	new = new_inode(sb);
> >  	down_read(&kf_root->kernfs_rwsem);
> > -	inode = kernfs_get_inode(sb, info->root->kn);
> > +	inode = kernfs_get_inode_locked(sb, info->root->kn, &new);
> 
> What are you serializing against here? I've been looking at this as well
> recently, and I thought we could just get rid of the locking here. But
> on second look, I am not so sure what is correct.
> 
> Is there anything that serializes kernfs_get_tree() with root node
> removal?

That is a good question and honestly I didn't know the answer. After digging a
bit, I think 07/12 patch [1] of your series is right.

Superblock is still private here and it is added to the supers list after
kernfs_fill_super. Root removal is not serialized by kernfs and kernfs users
keep the root alive across the mount.

I can drop the kernfs_fill_super change from my patch and I think your patch
will cover it better.

[1] https://lore.kernel.org/20261016143806.2946578-8-jkoolstra@xs4all.nl

      reply	other threads:[~2026-10-19 23:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16 22:00 [PATCH v3] kernfs: allocate inodes and dentry outside kernfs_rwsem Shakeel Butt
2026-10-16 22:42 ` Tejun Heo
2026-10-17  9:14   ` Greg Kroah-Hartman
2026-10-17 17:21     ` Shakeel Butt
2026-10-18 20:47 ` Jori Koolstra
2026-10-19 23:34   ` Shakeel Butt [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ataWrUkD-rqeoFcV@linux.dev \
    --to=shakeel.butt@linux.dev \
    --cc=christian@brauner.io \
    --cc=driver-core@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=jkoolstra@xs4all.nl \
    --cc=kernel-team@meta.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.