On Thu, Mar 21, 2019 at 05:45:10PM -0400, Waiman Long wrote: > It was found that if a process had many pending signals (e.g. millions), > the act of exiting that process might cause its parent to have a hard > lockup especially on a debug kernel with features like KASAN enabled. > It was because the flush_sigqueue() was called in release_task() with > tasklist_lock held and irq disabled. This rather apocalyptic language is a bit uncalled for. I appreciate the warning is scary, but all that's really happening is that the debug code is taking too long to execute. > To avoid this dire condition and reduce lock hold time of tasklist_lock, > flush_sigqueue() is modified to pass in a freeing queue pointer so that > the actual freeing of memory objects can be deferred until after the > tasklist_lock is released and irq re-enabled. I think this is a really bad solution. It looks kind of generic, but isn't. It's terribly inefficient, and all it's really doing is deferring the debugging code until we've re-enabled interrupts. We'd be much better off just having a list_head in the caller and list_splice() the queue->list onto that caller. Then call __sigqueue_free() for each signal on the queue.
