linux-kernel - [PATCH v12 01/54] vfs: export new_inode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20220331153130.41287-2-jlayton@kernel.org>
Date:   Thu, 31 Mar 2022 11:30:37 -0400
From:   Jeff Layton <jlayton@...nel.org>
To:     ceph-devel@...r.kernel.org
Cc:     xiubli@...hat.com, idryomov@...il.com, lhenriques@...e.de,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Al Viro <viro@...iv.linux.org.uk>
Subject: [PATCH v12 01/54] vfs: export new_inode_pseudo

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. This is desirable behavior for most
filesystems, but doesn't work for ceph.

To work around all of this, just use new_inode_pseudo which doesn't add
it to the sb->s_inodes list.

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

diff --git a/fs/inode.c b/fs/inode.c
index 63324df6fa27..9ddf7d1a7359 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1025,6 +1025,7 @@ struct inode *new_inode_pseudo(struct super_block *sb)
 	}
 	return inode;
 }
+EXPORT_SYMBOL(new_inode_pseudo);

 /**
  *	new_inode 	- obtain an inode
-- 
2.35.1