linux-kernel - Re: Fwd: [PATCH] kmemcheck: SMP support

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>] [day] [month] [year] [list]

Date:	Sun, 25 May 2008 17:30:13 +0300
From:	Pekka Paalanen <pq@....fi>
To:	"Vegard Nossum" <vegard.nossum@...il.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>,
	"Pekka Enberg" <penberg@...helsinki.fi>,
	linux-kernel@...r.kernel.org
Subject: Re: Fwd: [PATCH] kmemcheck: SMP support

On Fri, 23 May 2008 16:19:43 +0200
"Vegard Nossum" <vegard.nossum@...il.com> wrote:

> Oops, forgot to put you on Cc. I thought you might find this
> interesting as well... :-)

Yes, thanks. My opinion is that mmiotrace can live well enough with
runtime-disabling extra cpus when tracing starts. Multi-cpu effects to
hardware access are not really in the focus but seeing the access in
the first place. I'd rather wait to see if the per-cpu page table
feature starts to evolve.

I quickly read through your code and tried to come up with race
scenarios, but failed. Ok, one question which might be far fetched:
is there a window for things to go wrong, when one cpu has faulted
and is submitting the NMI, but another cpu is managing cpus' online
state at the time? Is there a place in the cpu state management
that might fault at a point where cpu maps are inconsistent?
I doubt, but I don't know. And of course this could be a problem
only when something is bringing cpus on- or offline.

Btw. isn't reserving a cpumask_t variable from the stack discouraged
because it might have to deal with thousands of cpus and consume a
lot of memory?

Thanks.

> ---------- Forwarded message ----------
> From: Vegard Nossum <vegard.nossum@...il.com>
> Date: Fri, May 23, 2008 at 4:17 PM
> Subject: [PATCH] kmemcheck: SMP support
> To: Ingo Molnar <mingo@...e.hu>, Pekka Enberg <penberg@...helsinki.fi>
> Cc: linux-kernel@...r.kernel.org
> 
> 
> Hi,
> 
> This works on real hw, but not on qemu. It seems to get stuck waiting for one
> of the atomic values to change. Don't know why yet, it might just be yet
> another bug in qemu... (we've hit at least two of them so far. And they were
> real bugs too.)
> 
> But do you think this approach is feasible? It will kill interactivity,
> that's for sure, though only when kmemcheck is run-time enabled and number
> of CPUs > 1 (the more the worse).
> 

-- 
Pekka Paalanen
http://www.iki.fi/pq/
--
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/