Re: [PATCH] vfs: avoid spurious dentry ref/unref cycle on open

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



do you plan to submit this to next?

anything this is waiting for?

my quick skim suggests this only needs more testing (and maybe a review)

On Wed, Aug 7, 2024 at 10:38 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> On Wed, Aug 07, 2024 at 01:43:48PM +0100, Al Viro wrote:
> > On Wed, Aug 07, 2024 at 11:50:50AM +0200, Mateusz Guzik wrote:
> >
> > > tripping ip:
> > > vfs_tmpfile+0x162/0x230:
> > > fsnotify_parent at include/linux/fsnotify.h:81
> > > (inlined by) fsnotify_file at include/linux/fsnotify.h:131
> > > (inlined by) fsnotify_open at include/linux/fsnotify.h:401
> > > (inlined by) vfs_tmpfile at fs/namei.c:3781
> >
> > Try this for incremental; missed the fact that finish_open() is
> > used by ->tmpfile() instances, not just ->atomic_open().
> >
> > Al, crawling back to sleep...
>
> I _really_ hate ->atomic_open() calling conventions; FWIW, I suspect
> that in the current form this series is OK, but only because none
> of the existing instances call finish_open() on a preexisting
> aliases found by d_splice_alias().  And control flow in the
> instances (especially the cleanup paths) is bloody awful...
>
> We never got it quite right, and while the previous iterations of
> the calling conventions for that methods had been worse, it's still
> nasty in the current form ;-/
>
> Oh, well - review of those has been long overdue.



-- 
Mateusz Guzik <mjguzik gmail.com>





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux