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

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: <CAGudoHHF-j5kLQpbkaFUUJYLKZiMcUUOFMW1sRtx9Y=O9WC4qw@mail.gmail.com>
Date: Tue, 20 Aug 2024 13:38:05 +0200
From: Mateusz Guzik <mjguzik@...il.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: brauner@...nel.org, jack@...e.cz, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] vfs: avoid spurious dentry ref/unref cycle on open

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@...iv.linux.org.uk> 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>