linux-kernel - Re: [PATCH v2] exit: perform randomness and pid work without tasklist

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: <87ikpubt4c.fsf@email.froward.int.ebiederm.org>
Date: Fri, 31 Jan 2025 14:55:47 -0600
From: "Eric W. Biederman" <ebiederm@...ssion.com>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: brauner@...nel.org,  oleg@...hat.com,  akpm@...ux-foundation.org,
  linux-mm@...ck.org,  linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] exit: perform randomness and pid work without
 tasklist_lock

Oleg asked that I take a look, and I took one.

I very much agree with Oleg that this should be one patch per thing
you want to effect as the issues can be intricate in this part of
the code.

Moving proc_flush_pid inside of tasklist_lock is a bad idea.  The code
has previously been several kinds of a sore spot.  If you look at
proc_invalidate_siblings_dcache you can see calls to d_invalidate,
deactivate_super, and a few other vfs calls that could potentially do
quite a lot of work and potentially take a number of locks.  It has been
a long time but I remember when we used to flush the proc entries under
the tasklist_lock that there were actual deadlocks caused by some rare
code paths that were trying to free memory to allocate memory to make
progress.

It is wrong that attach_pid/detach_pid can be performed without the
tasklist_lock.  There are reasonable guarantees provided by the posix
standard that the set of processes sent a signal is the set of
processes at a point in time.  The tasklist_lock is how we provide
those guarantees currently.

There are two more layers to pids.  The pid number allocation of
alloc_pid/free_pid, and the struct pid layer maintained by get_pid,
put_pid.  Those two layers don't need the tasklist_lock.

It is safe to move free_pid out of tasklist_lock.  I am not certain
how sane it is.

Eric