linux-kernel - Re: [PATCHv2 2/2] tracing,mm - add kernel pagefault tracepoint for x86 & x86

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: <20101115145359.GC5410@nowhere>
Date:	Mon, 15 Nov 2010 15:54:02 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Jiri Olsa <jolsa@...hat.com>, mingo@...e.hu, rostedt@...dmis.org,
	lwoodman@...hat.com, hch@...radead.org,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCHv2 2/2] tracing,mm - add kernel pagefault tracepoint for
	x86 & x86_64

On Mon, Nov 15, 2010 at 03:06:33PM +0100, Andi Kleen wrote:
> > Actually I don't see any reason right now to trace only kernel faults. Do you?
> > If that's needed, one can still check on post-processing that the address
> > was in the kernel.
> 
> I think the idea is to get more context on oopses. If the event only covers
> that the overhead in the common case (minus *_user) is much less,
> versus the more generalized points you use.

I see. OTOH, page faults should be pretty low freq events most of time,
probably not something that would add much tracing overhead.

The pity is that we have something like exclude_user/exclude_kernel
properties for events when used by perf, but we consider trace event
as always firing in the kernel, this one is an exception but it would
too tricky and too much an overkill to handle these attributes just
for this trace events.

> For tracing the whole page fault me think it's better to have 
> a generalized exception tracer with a filter on page fault.

You're right. A tracepoint in handle_mm_fault() would be perhaps
better. It should catch most tracepoints the users are interested
in. On the other hand we may miss part of the page fault
latency, like the mmap_sem contention. This can be measured using
lock events though.

But I'm probably missing other important things.

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