linux-kernel - Re: [Patch -tip 3/3] Tracing/ftrace: Don't consume entries unhandled by mmiotrace

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: <c62985530809250913q227a5876k19b1b0ec591ad3cd@mail.gmail.com>
Date:	Thu, 25 Sep 2008 18:13:44 +0200
From:	"Frédéric Weisbecker" <fweisbec@...il.com>
To:	"Pekka Paalanen" <pq@....fi>
Cc:	"Ingo Molnar" <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [Patch -tip 3/3] Tracing/ftrace: Don't consume entries unhandled by mmiotrace

2008/9/25 Pekka Paalanen <pq@....fi>:
> We can (must) return to this if/when multiple tracers are allowed
> to be active simultaneously. But in the current situation, I do not
> see a way to trace more than one thing, but I haven't really looked
> into the other tracers.

You can enable another tracer simultaneously. I never tried it but you can
launch one from debugfs and another from kernel code for example.
The new boot tracer will have to launch the sched_switch tracer.
And since the functions which display the sched_switch entries are
already inside
trace.c I wanted to relay the display to the "default display
functions". That's one of
the reason of my patch (+ the bug).
But I could proceed in a another way than default relaying. Why not
using a function exported
by the tracing engine to display sched_switches.

> but tracing functions is useless
> or harmful in the usual use case of mmiotrace, i.e. tracing a binary-only
> proprietary driver. The functions will be anonymous anyway, and we can't
> disassemble the driver due to possible legal reasons. That's why mmiotrace
> does not even collect instruction pointers by default, although it
> supports them (or did, can't recall if it works now, since it hasn't been
> needed). I assume the goal is to create a free open driver without any
> legal issues by watching what the proprietary driver does.
>
> Even if the log would be cluttered with MMIO from other, uninteresting
> drivers, you can use the physical address to filter the entries by
> device (and therefore driver) afterwards. This is one reason why
> an mmiotrace log starts with the contents of /proc/bus/pci/devices.
>
> Was there some other scenario you were thinking about?

When I wanted to help on the ath5k project, I used to compare madwifi
traces with the ath5k traces. The goal was to find where was the
trouble when support for ar2425 cards didn't worked.
And I wanted to see the name of the functions where the code entered
to see where I was in the traces. That's why I wanted to have
an mmiotrace_printk function primarily :)
But I think one could use it for debugging too. Just to know where we
are in the trace.
--
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/