archive mirror
 help / color / mirror / Atom feed
From: Miklos Szeredi <>
To: Linus Torvalds <>
Cc: Linux Kernel Mailing List <>,
	linux-fsdevel <>,
	overlayfs <>,
	Al Viro <>
Subject: Re: [PATCH] ovl: set I_CREATING on inode being created
Date: Wed, 22 Aug 2018 21:58:15 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Aug 22, 2018 at 4:53 PM, Linus Torvalds
<> wrote:
> On Wed, Aug 22, 2018 at 1:55 AM Miklos Szeredi <> wrote:
>> +       spin_lock(&inode->i_lock);
>> +       inode->i_state |= I_CREATING;
>> +       spin_unlock(&inode->i_lock);
>> +
> Why is that spinlock protection there?
> Isn't this a new inode that cannot possibly be reached any other way yet?

new_inode() puts it on sb->s_inodes list, so it *is* reachable.
Following operate on s_inodes:

- evict_inodes() called from generic_shutdown_super(): a) we shouldn't
get here while in creation, b) it's careful to not touch inodes with
non-zero refcount

- invalidate_inodes(), called from block devices, so it doesn't apply
to overlayfs, also it skips inodes with non-zero refcount

- iterate_bdevs(), operates on blockdev_superblock

- fsnotify_unmount_inodes() called from generic_shutdown_super(): we
shouldn't get here while in creation,

- add_dquot_ref(), remove_dquot_ref(): not quite sure what these do,
but quotas are not (yet) supported on overlayfs

So looks like we are safe without a spinlock.

And there's another, more fundamental reason: if anything starts
messing with i_state of an inode that is not yet even had its state
changed to I_NEW, then lots of filesystems are in trouble.

> NOTE! This is a question. Maybe there is something I missed, and there
> *are* other ways to reach that inode. But if that's true, isn't it
> already too late to set I_CREATING?

No, it's not too late, I_CREATING can be set anytime up to
inode_insert5(), which is the first one to actually look at that flag.

> So I'd like some clarification on this point before applying it. It's
> possible that the spinlock is required, I just want to understand why.

I added the spinlock, because it's cheap (new_inode() already pulls it
into L1 cache) and because it's much harder to prove that lockless one
is correct than just adding that locking.


  reply	other threads:[~2018-08-22 23:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-22  8:55 [PATCH] ovl: set I_CREATING on inode being created Miklos Szeredi
2018-08-22 14:53 ` Linus Torvalds
2018-08-22 19:58   ` Miklos Szeredi [this message]
2018-08-22 20:14     ` Linus Torvalds

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:

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

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).