linux-kernel - Re: [rfc] "fair" rw spinlocks

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]

Date:	Thu, 10 Dec 2009 02:31:39 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	paulmck@...ux.vnet.ibm.com
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Christoph Hellwig <hch@...radead.org>,
	Nick Piggin <npiggin@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [rfc] "fair" rw spinlocks

"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> writes:

> My main concern would be "fork storms", where each CPU in a large
> system is spawning children in a pgrp that some other CPU is attempting
> to kill.  The CPUs spawning children might be able to keep ahead of
> the single CPU, so that the pgrp never is completely killed.
>
> Enlisting the aid of the CPUs doing the spawning (e.g., by having them
> consult a list of signals being sent) prevents this fork-storm scenario.

We almost have a worst case bound. We can have at most max_thread
processes.  Unfortunately it appears we don't force an rcu grace
period anywhere.  So It does appear theoretically possible to fork and
exit on a bunch of other cpus infinitely extending the rcu interval.

Still that is all inside the tasklist_lock, which serializes all of those
other cpus.  So as long as the cost of queuing signals is less than the
cost of adding processes to the task lists we won't have a problem.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/