linux-kernel - Re: [PATCH, RFC, tip/core/rcu] v3 scalable classic RCU implementation

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 31 Aug 2008 10:55:14 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Manfred Spraul <manfred@...orfullife.com>
Cc:	Lai Jiangshan <laijs@...fujitsu.com>, linux-kernel@...r.kernel.org,
	cl@...ux-foundation.org, mingo@...e.hu, akpm@...ux-foundation.org,
	dipankar@...ibm.com, josht@...ux.vnet.ibm.com, schamp@....com,
	niv@...ibm.com, dvhltc@...ibm.com, ego@...ibm.com,
	rostedt@...dmis.org, peterz@...radead.org,
	benh@...nel.crashing.org, davem@...emloft.net, tony.luck@...el.com
Subject: Re: [PATCH, RFC, tip/core/rcu] v3 scalable classic RCU
	implementation

On Sun, Aug 31, 2008 at 07:45:02PM +0200, Manfred Spraul wrote:
> Paul E. McKenney wrote:
>> Assuming that the ordering of processing pending irqs and marking the
>> CPU offline in cpu_online_mask can be resolved as noted above, it should
>> work fine -- if a CPU's bit is clear, we can safely ignore it.  The race
>> can be resolved by checking the CPU's bit in force_quiescent_state().
>>
>> Or am I missing something?
>>   
> Yes, that would work:
> Rule 1: after CPU_DEAD, a cpu is gone. The cpu is quiet, rcu callbacks must 
> be moved to other cpus, ...
> Rule 2: if a cpu is not listed in cpu_online_mask, then it can be 
> considered as outside a read-side critical section.
>
> The problem with rule 2 is that it means someone [force_quiescent_state()] 
> must poll the cpu_online_mask and look for changes.
> I'd really prefer a notifier. CPU_DYING is nearly the correct thing, it 
> only has to be moved down 3 lines ;-)
> (I want to kill the bitmaps, not add a hierarchical bitmap polling system!)

But some later CPU_DYING notifier might decide that the CPU cannot be
removed after all, which would mean bringing the CPU back.  And then
whatever the CPU was needed for might have actually happened in the
meantime, which does not sound good to me...

>> It is entirely possible that rcu_try_flip_waitack() and
>> rcu_try_flip_waitmb() need to check the AND of rcu_cpu_online_map and
>> cpu_online_map.  If this really is a problem (and it might well be),
>> then the easiest fix is to check for cpu_is_offline(cpu) in both
>> rcu_try_flip_waitmb_needed() and rcu_try_flip_waitack_needed(), and
>> that in both versions of both functions.  Thoughts?
>>   
> I made a mistake, get_online_cpus() stores current, not a cpu number. Thus 
> the described race it not possible. Perhaps there are other users that 
> could deadlock.
> I don't know enough about the preempt algorithm, thus I can't confirm if 
> your proposal would work or not.

Well, that is on my list of things to look into...

							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/