linux-kernel - Re: [patch] i386/x86_64: smp_call

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, 08 Feb 2007 12:43:28 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	heiko.carstens@...ibm.com
Cc:	akpm@...l.org, mingo@...e.hu, ak@...e.de, jan.glauber@...ibm.com,
	schwidefsky@...ibm.com, linux-kernel@...r.kernel.org
Subject: Re: [patch] i386/x86_64: smp_call_function locking inconsistency

From: Heiko Carstens <heiko.carstens@...ibm.com>
Date: Thu, 8 Feb 2007 21:32:10 +0100

> So either all spin_lock_bh's should be converted to spin_lock,
> which would limit smp_call_function()/smp_call_function_single()
> to process context & irqs enabled.
> Or the spin_lock's could be converted to spin_lock_bh which would
> make it possible to call these two functions even if in softirq
> context. AFAICS this should be safe.

Sparc64 does not allow smp_call_function() from software interrupts
either.

Same for powerpc, mips, alpha.

IA-64 has the inconsistency you've spotted between smp_call_function()
and smp_call_function_single().

In short, it's a mess :-)

I think it's logically simpler if we disallow smp_call_function*()
from any kind of asynchronous context.  But I'm sure your driver
has a true need for this for some reason.
-
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/