linux-kernel - Re: [PATCH] close_files(): reimplement based on do_close_on

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGudoHHwzzL-hVrbKV05wkFedY8eWHsZToEHFu_odfysz21gWg@mail.gmail.com>
Date: Wed, 14 Aug 2024 07:34:30 +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] close_files(): reimplement based on do_close_on_exec()

On Wed, Aug 14, 2024 at 7:24 AM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> On Mon, Aug 12, 2024 at 09:56:58AM +0200, Mateusz Guzik wrote:
> > While here take more advantage of the fact nobody should be messing with
> > the table anymore and don't clear the fd slot.
> >
> > Signed-off-by: Mateusz Guzik <mjguzik@...il.com>
> > ---
> >
> > how about this instead, I think it's a nicer clean up.
>
> > It's literally do_close_on_exec except locking and put fd are deleted.
>
> TBH, I don't see much benefit that way - if anything, you are doing
> a bunch of extra READ_ONCE() of the same thing (files->fdt), for no
> visible reason...

I claim the stock code avoidably implements traversal differently from
do_close_on_exec.

The fdt reload can be trivially lifted out of the loop, does not
affect what I was going for.

But now that you mention this can also be done in the do_close_on_exec
case -- the thread calling it is supposed to be the only consumer, so
fdt can't change.

that's my $0,03 here, I'm not going to further argue about it
-- 
Mateusz Guzik <mjguzik gmail.com>