linux-kernel - Re: [PATCHSET] stop_machine: implement stop_machine_from_offline

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: <1308226219.13240.41.camel@twins>
Date:	Thu, 16 Jun 2011 14:10:19 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Tejun Heo <tj@...nel.org>
Cc:	x86@...nel.org, mingo@...e.hu, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org, suresh.b.siddha@...el.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCHSET] stop_machine: implement
 stop_machine_from_offline_cpu()

On Tue, 2011-06-14 at 19:06 +0200, Tejun Heo wrote:
> This three patch series implements stop_machine_from_offline_cpu(),
> which is stop_machine() which can be used from a CPU which isn't yet
> online.
> 
> This is for mtrr which needs stop_machine while bringing up a CPU.  It
> currently implements its own stop_machine directly using
> stop_one_cpu().  Duplicating such core functionality is wasteful and
> fragile.  e.g. mtrr's implementation currently can deadlock against
> generic stop_machine().
> 
> This patchset is born from Suresh's attempt at implementing similar
> feature into [__]stop_machine()[1], which IMHO is a bit too subtle.
> Given the peculiarity of the feature, I think it's better to have
> dedicated function with an ugly name.  Also, this way, the
> implementation is very well isolated from the rest of stop_cpus
> machinery and much simpler. 

Maybe a silly question, but why does mtrr need all this? Surely mtrr can
serialize state by other means than stopping all cpus. A simple mutex
around the shared state blocking other cpus from updating the mtrr state
while we're copying the state to our newly born cpu should cure things.

I'm sure I'm missing something trivial here, but shouldn't we at least
explain the details and explore alternatives before merging ugly code?


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