On 02/24, Andrei Vagin wrote: > > On Tue, Feb 24, 2026 at 9:02 AM Pavel Tikhomirov > <[email protected]> wrote: > > > > This moves the condition (tid != 1 && !tmp->child_reaper) to after idr > > alloc, so it not only covers that first process in pid namespace has pid > > 1 in case of clone3(set_tid) requesting wrong pid, but also if idr > > itself gives wrong pid for some reason. > > > > This could've been the case before this patch, when creating first > > process the alloc_pid()->pidfs_add_pid() code path fails, so that the > > idr->idr_next is non zero anymore and next process calling to > > alloc_pid(), will get 2 as a pid from idr_alloc_cyclic(). Effectively > > leading to init-less pid namespace, which is a bug. > > I don't think this is an issue right now, as we only allow one attempt > to create the init. If that first attempt fails, free_pid will disable > further PID allocations in the target namespace.
Thanks, you are right! > This isn't directly related to this patch, but why do we check > "ns->pid_allocated & PIDNS_ADDING" after allocating all pids? Wouldn't > it be more reasonable to do that right after taking the pidmap_lock? Perhaps, but alloc_pid() can drop pidmap_lock and retry, so we will need to re-check PIDNS_ADDING. Oleg.
