linux-kernel - Re: [BUG/PATCH] x86 mmiotrace: dynamically disable non-boot 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: <20080416183258.GA30490@elte.hu>
Date:	Wed, 16 Apr 2008 20:32:58 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Pekka Paalanen <pq@....fi>
Cc:	Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
	vegard.nossum@...il.com, nouveau@...ts.freedesktop.org
Subject: Re: [BUG/PATCH] x86 mmiotrace: dynamically disable non-boot CPUs

* Pekka Paalanen <pq@....fi> wrote:

> > yeah - it looks complex. Not a showstopper for now :-)
> > 
> > but given that Xorg is usually just a single task, do we _really_ 
> > need this?
> 
> We're not tracing Xorg at all. Mmiotrace still cannot catch accesses 
> originating in user space. It is tracing MMIO accesses from within the 
> kernel, and this means that IRQ services and device syscalls may be 
> accessing the hardware at the same time. Vblank interrupts happen 
> quite often, some GPU commands are actually emulated in kernel via 
> interrupts and whatnot. [...]

ok, understood - i forgot about IRQ generated GPU accesses. In fact UP 
probably generates a more readable trace because DRM accesses from one 
CPU are not mixed up with IRQ completion from another CPU.

So i think we need to fix your automatic-cpudown/cpuup patch. I tried 
that and it worked very intuitively and the cpus were disabled/enabled 
without any trouble - with ftrace based mmiotrace we now basically have 
something that most distros could enable by default without thinking 
twice about it.

But if it means an UP kernel has to be used then it will be turned off 
immediately and the barrier to users will be huge again. I really 
envision mmiotrace to be usable by default on _any_ generic distro, 
without rebooting and without any hassle on the user's part.

the automatic drop-to-single-CPU-when-tracing solution from you is OK - 
it will also test our CPU hotplug primitives some more ;-) And it's not 
like users expect a mmiotraced X session to be particularly fast, right?

so lets fix those preemptability bugs. They show that the 
cpu-up/cpu-down ops are called from atomic context - it should normally 
be straightforward to sort out - there's no particular reason why the 
->open()/->close() methods of an ftrace plugin should run in atomic 
context. Steve, any ideas where the atomicity might come from?

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