| Message ID | 20200914191707.380444-2-jlayton@kernel.org (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | ceph+fscrypt: context, filename and symlink support | expand |
On Mon, Sep 14, 2020 at 03:16:52PM -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> I'd still like to see an explanation for why ilookup5() shouldn't be fixed instead. - Eric
On Mon, Sep 14, 2020 at 03:16:52PM -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. Er... Why would you _not_ want -ESTALE in that situation?
On Wed, 2020-09-23 at 04:41 +0100, Al Viro wrote: > On Mon, Sep 14, 2020 at 03:16:52PM -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. > > Er... Why would you _not_ want -ESTALE in that situation? I'm hashing the new inode just before sending the create request to the MDS. When the reply comes in, the client then searches for that inode in the hash. If I_NEW has been cleared in the meantime -- no problem. If not, then we want the task handling the reply to wait until it is (and not get back an -ESTALE).
diff --git a/fs/inode.c b/fs/inode.c index 72c4c347afb7..61554c2477ab 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
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(+)