iput() ends up calling ->evict() on new inode, which is not yet initialized
by owning fs. So use destroy_inode() instead.
Add to sb->s_inodes list only after the inode has been inserted into the
hash. The exact point at which the inode is added onto the sb list
shouldn't matter as long as it is done while the inode is in the I_NEW
state.
Reported-by: Al Viro <[email protected]>
Signed-off-by: Miklos Szeredi <[email protected]>
Fixes: 80ea09a002bf ("vfs: factor out inode_insert5()")
---
fs/inode.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index 2c300e981796..2f6b411b904f 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1094,12 +1094,14 @@ struct inode *iget5_locked(struct super_block *sb, unsigned long hashval,
struct inode *inode = ilookup5(sb, hashval, test, data);
if (!inode) {
- struct inode *new = new_inode(sb);
+ struct inode *new = new_inode_pseudo(sb);
if (new) {
inode = inode_insert5(new, hashval, test, set, data);
if (unlikely(inode != new))
- iput(new);
+ destroy_inode(new);
+ else
+ inode_sb_list_add(inode);
}
}
return inode;
--
2.14.3
On Fri, Jul 06, 2018 at 05:35:48PM +0200, Miklos Szeredi wrote:
> iput() ends up calling ->evict() on new inode, which is not yet initialized
> by owning fs. So use destroy_inode() instead.
>
> Add to sb->s_inodes list only after the inode has been inserted into the
> hash. The exact point at which the inode is added onto the sb list
> shouldn't matter as long as it is done while the inode is in the I_NEW
> state.
>
> Reported-by: Al Viro <[email protected]>
> Signed-off-by: Miklos Szeredi <[email protected]>
> Fixes: 80ea09a002bf ("vfs: factor out inode_insert5()")
Check 22dc9a168272 (new primitive: discard_new_inode()) in vfs.git; IMO yours
should go on top of that and I would seriously consider going for just
alloc_inode() - to hell with new_inode_pseudo(). I_CREATING gives an easy
way for insert_inode5() to decide whether we need to move into ->i_sb_list...