diff mbox series

[RFC,v5,01/19] vfs: export new_inode_pseudo

Message ID 20210326173227.96363-2-jlayton@kernel.org
State Superseded
Headers show
Series [RFC,v5,01/19] vfs: export new_inode_pseudo | expand

Commit Message

Jeff Layton March 26, 2021, 5:32 p.m. UTC
Ceph needs to be able to allocate inodes ahead of a create that might
involve a fscrypt-encrypted inode. new_inode() almost fits the bill,
but it puts the inode on the sb->s_inodes list and when we go to hash
it, that might be done again.

We could work around that by setting I_CREATING on the new inode, but
that causes ilookup5 to return -ESTALE if something tries to find it
before I_NEW is cleared. To work around all of this, just use
new_inode_pseudo which doesn't add it to the list.

Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/inode.c | 1 +
 1 file changed, 1 insertion(+)

Comments

Eric Biggers April 8, 2021, 1:08 a.m. UTC | #1
On Fri, Mar 26, 2021 at 01:32:09PM -0400, Jeff Layton wrote:
> Ceph needs to be able to allocate inodes ahead of a create that might

> involve a fscrypt-encrypted inode. new_inode() almost fits the bill,

> but it puts the inode on the sb->s_inodes list and when we go to hash

> it, that might be done again.

> 

> We could work around that by setting I_CREATING on the new inode, but

> that causes ilookup5 to return -ESTALE if something tries to find it

> before I_NEW is cleared. To work around all of this, just use

> new_inode_pseudo which doesn't add it to the list.

> 

> Cc: Al Viro <viro@zeniv.linux.org.uk>

> Signed-off-by: Jeff Layton <jlayton@kernel.org>


IIRC, this looked like a bug in ilookup5().  Did you come to the conclusion that
it's not actually a bug?

- Eric
Jeff Layton April 8, 2021, 4:18 p.m. UTC | #2
On Wed, 2021-04-07 at 18:08 -0700, Eric Biggers wrote:
> On Fri, Mar 26, 2021 at 01:32:09PM -0400, Jeff Layton wrote:

> > Ceph needs to be able to allocate inodes ahead of a create that might

> > involve a fscrypt-encrypted inode. new_inode() almost fits the bill,

> > but it puts the inode on the sb->s_inodes list and when we go to hash

> > it, that might be done again.

> > 

> > We could work around that by setting I_CREATING on the new inode, but

> > that causes ilookup5 to return -ESTALE if something tries to find it

> > before I_NEW is cleared. To work around all of this, just use

> > new_inode_pseudo which doesn't add it to the list.

> > 

> > Cc: Al Viro <viro@zeniv.linux.org.uk>

> > Signed-off-by: Jeff Layton <jlayton@kernel.org>

> 

> IIRC, this looked like a bug in ilookup5().  Did you come to the conclusion that

> it's not actually a bug?

> 


Yes. Al pointed out that it's desirable behavior for most (simpler)
filesystems.

Basically, nothing should have presented the filehandle for this inode
to a client until after I_NEW has been cleared. So, any attempt to look
it up should give you back ESTALE at this point.

I'm not married to this approach however. If there's a better way to do
this, then I'm happy to consider it.
-- 
Jeff Layton <jlayton@kernel.org>
diff mbox series

Patch

diff --git a/fs/inode.c b/fs/inode.c
index a047ab306f9a..0745dc5d0924 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -935,6 +935,7 @@  struct inode *new_inode_pseudo(struct super_block *sb)
 	}
 	return inode;
 }
+EXPORT_SYMBOL(new_inode_pseudo);
 
 /**
  *	new_inode 	- obtain an inode