linux-kernel - Re: [PATCH] Fix x86_64 _spin_lock

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: <44EE8BA8.2090706@yahoo.com.au>
Date:	Fri, 25 Aug 2006 15:33:28 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Andrew Morton <akpm@...l.org>
CC:	Andi Kleen <ak@...e.de>, Edward Falk <efalk@...gle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Fix x86_64 _spin_lock_irqsave()

Andrew Morton wrote:
> On 24 Aug 2006 08:45:11 +0200
> Andi Kleen <ak@...e.de> wrote:
> 
> 
>>Edward Falk <efalk@...gle.com> writes:
>>
>>
>>>Add spin_lock_string_flags and _raw_spin_lock_flags() to
>>>asm-x86_64/spinlock.h so that _spin_lock_irqsave() has the same
>>>semantics on x86_64 as it does on i386 and does *not* have interrupts
>>>disabled while it is waiting for the lock.
>>
>>Did it fix anything for you?
>>
> 
> 
> It's the rendezvous-via-IPI problem.  Suppose we want to capture all CPUs
> in an IPI handler (TSC sync, for example).
> 
> - CPUa holds read_lock(&tasklist_lock)
> - CPUb is spinning in write_lock_irq(&taslist_lock)
> - CPUa enters its IPI handler and spins
> - CPUb never takes the IPI and we're dead.
> 
> Re-enabling interrupts while we spin will prevent that.  But I suspect that
> if we ever want to implement IPI rendezvous (and cannot use the
> stop_machine_run() thing) then we might still have problems.  A valid
> optimisation (which we use in some places) is:
> 
> 	local_irq_save(flags);
> 	<stuff>
> 	write_lock(lock);

Yes, or it may be taken inside a section that needs interrupts off for
correctness (eg. if it is holding an irq safe lock). And in the current
implementation I don't think the plain _irq variants reenable interrupts
because that would require reading the register.

Would it be sufficient to just do pair-wise rendezvous, where the
initiating CPU is in a known good state? For TSC sync it might be...

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 
-
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/