Re: d_instantiate() and unlock_new_inode() order in btrfs_mkdir()

2018-04-18 Thread Eric Biggers
On Thu, Apr 19, 2018 at 01:15:59AM +0100, Al Viro wrote: > On Thu, Apr 19, 2018 at 01:06:13AM +0100, Al Viro wrote: > > On Wed, Apr 18, 2018 at 05:00:29PM -0700, Eric Biggers wrote: > > > Hi Chris and other btrfs folks, > > > > > > btrfs_mkdir() calls d_instantiate() before unlock_new_inode(),

Re: d_instantiate() and unlock_new_inode() order in btrfs_mkdir()

2018-04-18 Thread Al Viro
On Thu, Apr 19, 2018 at 01:06:13AM +0100, Al Viro wrote: > On Wed, Apr 18, 2018 at 05:00:29PM -0700, Eric Biggers wrote: > > Hi Chris and other btrfs folks, > > > > btrfs_mkdir() calls d_instantiate() before unlock_new_inode(), which is > > wrong > > because it exposes the inode to lookups

Re: d_instantiate() and unlock_new_inode() order in btrfs_mkdir()

2018-04-18 Thread Al Viro
On Wed, Apr 18, 2018 at 05:00:29PM -0700, Eric Biggers wrote: > Hi Chris and other btrfs folks, > > btrfs_mkdir() calls d_instantiate() before unlock_new_inode(), which is wrong > because it exposes the inode to lookups before it's been fully initialized. Huh? It *is* fully initialized by that

d_instantiate() and unlock_new_inode() order in btrfs_mkdir()

2018-04-18 Thread Eric Biggers
Hi Chris and other btrfs folks, btrfs_mkdir() calls d_instantiate() before unlock_new_inode(), which is wrong because it exposes the inode to lookups before it's been fully initialized. Most filesystems get it right, but f2fs and btrfs don't. I sent a f2fs patch