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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 21 Mar 2019 18:52:08 -0700 From: Matthew Wilcox <willy@...radead.org> To: Waiman Long <longman@...hat.com> Cc: Andrew Morton <akpm@...ux-foundation.org>, Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>, David Rientjes <rientjes@...gle.com>, Joonsoo Kim <iamjoonsoo.kim@....com>, linux-kernel@...r.kernel.org, linux-mm@...ck.org, selinux@...r.kernel.org, Paul Moore <paul@...l-moore.com>, Stephen Smalley <sds@...ho.nsa.gov>, Eric Paris <eparis@...isplace.org>, "Peter Zijlstra (Intel)" <peterz@...radead.org>, Oleg Nesterov <oleg@...hat.com> Subject: Re: [PATCH 2/4] signal: Make flush_sigqueue() use free_q to release memory 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.
Powered by blists - more mailing lists