Re: [tip:perfcounters/core] perf_counter: x86: Fix call-chainsupport to use NMI-safe methods

[Mathieu Desnoyers]

* H. Peter Anvin (hpa@xxxxxxxxx) 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?

Mathieu


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

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/