linux-kernel - Re: [RFC PATCH v v2 0/4] avoid the extra atomic on a ref when closing a fd

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: <CAGudoHFQioKFuxXesPbfHbjdWpqTs-_J2Ss0dVrr218ih0XPtQ@mail.gmail.com>
Date: Wed, 5 Mar 2025 13:42:16 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: Christian Brauner <brauner@...nel.org>
Cc: viro@...iv.linux.org.uk, jack@...e.cz, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org
Subject: Re: [RFC PATCH v v2 0/4] avoid the extra atomic on a ref when closing
 a fd

On Wed, Mar 5, 2025 at 11:38 AM Christian Brauner <brauner@...nel.org> wrote:
>
> On Tue, Mar 04, 2025 at 07:35:02PM +0100, Mateusz Guzik wrote:
> > The stock kernel transitioning the file to no refs held penalizes the
> > caller with an extra atomic to block any increments.
> >
> > For cases where the file is highly likely to be going away this is
> > easily avoidable.
> >
> > In the open+close case the win is very modest because of the following
> > problems:
> > - kmem and memcg having terrible performance
>
> I thought that was going to be addressed by Vlastimil, i.e., the mm guys
> to provide a new memcg api.

afaics this is for kmem only, no memcg support.

There is an old patch which sped up memcg, but got reverted and it is
on the table to bring it back, but Vlastimil is dragging his foot.

> > vast majority of last fputs are from remove_vma. I think that code wants
> > to be patched to batch them (as in something like fput_many should be
> > added -- something for later).
>
> We used to have that for io_uring and got rid of it. The less fput()
> primitives the better tbh. But let's see.
>

I would say a _many (or whatever) variant is pretty idiomatic, but I'm
not going to insist. This is a side remark to the patchset.

-- 
Mateusz Guzik <mjguzik gmail.com>