[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGudoHHgBwsN8SQBOGOD5ak1V2a6Fnr1jPPUS3VLNaxOpiyBSg@mail.gmail.com>
Date: Tue, 16 Dec 2025 11:02:33 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Tycho Andersen <tycho@...nel.org>, Christian Brauner <brauner@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] pid: remove unnecessary idr_preload()
On Tue, Dec 16, 2025 at 10:44 AM Oleg Nesterov <oleg@...hat.com> wrote:
>
> On 12/15, Tycho Andersen wrote:
> >
> > From: "Tycho Andersen (AMD)" <tycho@...nel.org>
> >
> > As near as I can tell, nothing in the second pidmap_lock critical section
> > actually allocates an id, so there is no need to do idr_preload().
> > idr_replace() does not, nor does pidfs_add_pid().
>
> Yes. The extra idr_preload() was needed for pidfs_add_pid() after the commit
> 9698d5a483654 ("pidfs: rework inode number allocation").
>
> But please see
> [PATCH v3 2/2] pid: only take pidmap_lock once on alloc
> https://lore.kernel.org/all/20251206131955.780557-3-mjguzik@gmail.com/
>
> This patch removes the unnecessary idr_preload() too.
>
The patch can be trivially rebased on top of this one (actual rebase
would be cumbersome; instead one can cp kernel/fork.c
kernel/fork.c-tmp, apply this patch on top of stock file, mv
kernel/fork.c-tmp kernel/fork.c and commit resulting diff).
However, unless someone is looking to put this into stable branches or
similar, I think the dance can be skipped at no loss for future
generations.
Powered by blists - more mailing lists