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]

Message-ID: <20091208013900.GU6808@linux.vnet.ibm.com>
Date:	Mon, 7 Dec 2009 17:39:00 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Andi Kleen <andi@...stfloor.org>,
	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>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: [rfc] "fair" rw spinlocks

On Mon, Dec 07, 2009 at 03:19:59PM -0800, Eric W. Biederman wrote:
> Andi Kleen <andi@...stfloor.org> writes:
> 
> > ebiederm@...ssion.com (Eric W. Biederman) writes:
> >
> >> "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> writes:
> >>>
> >>> Is it required that all of the processes see the signal before the
> >>> corresponding interrupt handler returns?  (My guess is "no", which
> >>> enables a trick or two, but thought I should ask.)
> >>
> >> Not that I recall.  I think it is just an I/O completed signal.
> >
> > Wasn't there the sysrq SAK too? That one definitely would need
> > to be careful about synchronicity.
> 
> SAK from sysrq is done through schedule work, I seem to recall the
> locking being impossible otherwise.  There is also send_sig_all and a
> few others from sysrq.  I expect we could legitimately make them
> schedule_work as well if needed.

OK, I will chance it...  Here is one possible trick:

o	Maintain a list of ongoing group-signal operations, protected
	by some suitable lock.  These could be in a per-chain-locked
	hash table, hashed by the signal target (e.g., pgrp).

o	When a task is created, it scans the above list, committing
	suicide (or doing whatever the signal requires) if appropriate.

o	When creating a child task, the parent holds an SRCU across
	creation.  It acquires SRCU before starting creation, and
	releases it when it knows that the child has completed
	scanning the above list.

o	The updater does the following:

	o	Add its request to the above list.

	o	Wait for an SRCU grace period to elapse.

	o	Kill off everything currently in the task list,
		and then wait for each such task to get to a point
		where it can be guaranteed not to spawn additional
		tasks.  (This might be mediated via a reference
		count in the corresponding list element, or by
		rescanning the task list, or any of a number of
		similar tricks.)

		Of course, if the signal is non-fatal, then it is
		necessary only to wait until the child has taken
		the signal.

	o	If it is possible for a given task's children to
		outlive it, despite the fact that the children must
		commit suicide upon finding themselves indicated by the
		list, wait for another SRCU grace period to elapse.
		(This additional SRCU grace period would be required
		for a non-fatal pgrp signal, for example.)

	o	Remove the element from the list.

Does this approach make sense, or am I misunderstanding the problem?

Either way, one additional question...  It seems to me that non-fatal
signals really don't require the above mechanism, because if a task
handles the signal, and then spawns a child, one can argue that the
child came after the signal and should thus be unaffected.  Right?
Or more confusion on my part?

							Thanx, Paul
--
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/