linux-kernel - Re: [PATCH 01/22] x86: add methods for writing of an MSR on several CPUs

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: <4A156361.2040507@zytor.com>
Date:	Thu, 21 May 2009 07:21:21 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Borislav Petkov <borislav.petkov@....com>
CC:	akpm@...ux-foundation.org, greg@...ah.com, mingo@...e.hu,
	norsk5@...oo.com, tglx@...utronix.de, mchehab@...hat.com,
	aris@...hat.com, edt@....ca, linux-kernel@...r.kernel.org,
	Andreas Herrmann <andreas.herrmann3@....com>
Subject: Re: [PATCH 01/22] x86: add methods for writing of an MSR on	several
 CPUs

Borislav Petkov wrote:
>>>
>> smp_call_function_many() does allow concurrent execution.
> 
> Well, IMHO, not an absolutely concurrent execution since you can't
> control at what moment in time the IPIs will be executed on each core,
> IOW, the respective call function IPIs will generally not coincide on
> each core at a given moment in time. This is especially true if you're
> sending IPIs to cores across nodes.
> 
> And there's hypothetically a small window where you might get an
> inconsistent MSR content across cores. It's a whole another question
> whether this is going to be relevant.
> 

It *allows* concurrent execution.  It doesn't *guarantee* concurrent
execution.  Looping with smp_call_function_one() means we wait for
synchronization after ever one.

>> Looping over a list with smp_call_function_one() -- which you
>> currently have -- is serializing, at which point we might just push
>> the loop into the caller rather than worrying about a new interface.
> 
> So, the actual question is do we need that done in msr.c? If there are
> no potential users, I could easily do the whole thing in the driver and
> do not touch x86 code.

Only if we care about the additional performance of having it be
nonserializing.

	-hpa
-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
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/