From: "Tycho Andersen (AMD)" <tycho@kernel.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().

I boot tested this and built a kernel on a $large core system, so hopefully
that would have caught any errors.

Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
---
 kernel/pid.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/kernel/pid.c b/kernel/pid.c
index a31771bc89c1..b0fefeb0a1ec 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -270,7 +270,6 @@ struct pid *alloc_pid(struct pid_namespace *ns, pid_t *set_tid,
 	INIT_HLIST_HEAD(&pid->inodes);
 
 	upid = pid->numbers + ns->level;
-	idr_preload(GFP_KERNEL);
 	spin_lock(&pidmap_lock);
 	if (!(ns->pid_allocated & PIDNS_ADDING))
 		goto out_unlock;
@@ -281,14 +280,12 @@ struct pid *alloc_pid(struct pid_namespace *ns, pid_t *set_tid,
 		upid->ns->pid_allocated++;
 	}
 	spin_unlock(&pidmap_lock);
-	idr_preload_end();
 	ns_ref_active_get(ns);
 
 	return pid;
 
 out_unlock:
 	spin_unlock(&pidmap_lock);
-	idr_preload_end();
 	put_pid_ns(ns);
 
 out_free:

base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
-- 
2.52.0

On 12/15, Tycho Andersen wrote:
>
> From: "Tycho Andersen (AMD)" <tycho@kernel.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.

Oleg.

On Tue, Dec 16, 2025 at 10:44 AM Oleg Nesterov <oleg@redhat.com> wrote:
>
> On 12/15, Tycho Andersen wrote:
> >
> > From: "Tycho Andersen (AMD)" <tycho@kernel.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.

On Tue, Dec 16, 2025 at 11:02:33AM +0100, Mateusz Guzik wrote:
> On Tue, Dec 16, 2025 at 10:44 AM Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > On 12/15, Tycho Andersen wrote:
> > >
> > > From: "Tycho Andersen (AMD)" <tycho@kernel.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.

Yeah, agreed. I think let's just take yours. I'll test it now.

Tycho

On 12/15, Tycho Andersen wrote:
>
> From: "Tycho Andersen (AMD)" <tycho@kernel.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.

Oleg.

On Tue, Dec 16, 2025 at 10:39:58AM +0100, Oleg Nesterov wrote:
> On 12/15, Tycho Andersen wrote:
> >
> > From: "Tycho Andersen (AMD)" <tycho@kernel.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/

Oh, nice. I was looking at doing this too. I'll head over to that
thread...

Tycho