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>
