linux-kernel - Re: [tip:perfcounters/core] perf_counter: x86: Fix call-chain support to use NMI-safe methods

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: <4A380000.5090206@zytor.com>
Date:	Tue, 16 Jun 2009 13:26:40 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
CC:	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	mingo@...hat.com, paulus@...ba.org, acme@...hat.com,
	linux-kernel@...r.kernel.org, penberg@...helsinki.fi,
	vegard.nossum@...il.com, efault@....de, jeremy@...p.org,
	npiggin@...e.de, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:perfcounters/core] perf_counter: x86: Fix call-chain	support
 to use NMI-safe methods

Mathieu Desnoyers wrote:
> * H. Peter Anvin (hpa@...or.com) wrote:
>> Mathieu Desnoyers wrote:
>>> With respect to cr2, yes, this is the only window we care about.
>>> However, the rest of vmalloc_fault() must be audited for other non
>>> nmi-suitable data structure use (e.g. "current"), which I did in the
>>> past.
>>>
>>> My intent was just to respond to Peter's concerns by showing that the
>>> part of page fault handler which needs to be NMI-reentrant is really not
>>> that big.
>>>
>> Even if that is true now, you want it to be true for all future time,
>> and all to support an out-of-tree piece of code.  All of this is
>> virtually impossible to test for without said out-of-tree piece of code,
>> so I will object to it anyway.
>>
> 
> I think we are confusing two very distinct topics here :
> 
> LTTng is currently out-of-tree. Yes. It does not have to stay like this
> in the future. Or it can be a different tracer, like ftrace for
> instance.
> 
> LTTng can be built as modules. This is very likely to stay like this
> even if LTTng (or parts of) are merged. Or as a different tracer is
> merged. The reason why building a tracer as a module is convenient for
> users has been expressed in a previous mail.
> 
> So now you argue that it should not be made easy to implement
> tracers/profilers so they can be built as kernel modules because the
> LTTng tracer is out-of-tree. I'm sorry, but I really don't follow your
> line of reasoning.
> 
> So let's say we merge tracer or profiler code into the mainline kernel
> and permit that code to be built as module, hence enable testing within
> the mainline tree, would you be fine with this?
> 

I'm saying that imposing constraints on kernel code has cost.  The cost
may not be immediately evident, but it constraints the kernel
development going forward, potentially for all times.  It is
particularly obnoxious with out-of-tree users, because it is impossible
to fix up those users to deal with a new interface, or even know what
their constraints really are.

This is part of the fundamental problem that Xen causes, for example.

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