linux-kernel - Re: [PATCH, RFC 0/3] Improvements to the tracing documentation

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: <20090413223526.GB32182@mit.edu>
Date:	Mon, 13 Apr 2009 18:35:26 -0400
From:	Theodore Tso <tytso@....edu>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Linux Kernel Developers List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH, RFC 0/3] Improvements to the tracing documentation

On Mon, Apr 13, 2009 at 11:31:24PM +0200, Ingo Molnar wrote:
> Cool. [ And i guess you'll like the per tracepoint filter 
> expressions too :-) ]

I haven't played with them yet, but I was looking over the source code
at them (since they aren't documented yet :-).  It looks like at the
moment only integer matches are allowed, right?  That's a bit of an
issue for me, since one of the things I'd really like to be able to do
is filter based on devname (i.e., sda2).  (Most of the time we only
want to collect information for a particular block device or
filesystem.)

Actually, the fact that I'm having to drop some 32 bytes for each jbd2
and ext4 trace log for the bdevname in the ring buffer is really for
the birds.  What I really want to do is just to drop in the dev_t, and
then for the tracing infrastructure to have an efficient (cached) way
of taking the dev_t and turning that back into struct block_device at
TP_printk time so we can print the bdevname when it's needed.  We
deifnitely don't want to be calling bdget() in fs/block_dev.c each
time we print a line in the tracing buffer!  I'm guessing that's
something the blktrace tracer would find handy as well.

Of course having more kernel code play with dev_t's directly isn't
considered politically correct in some circles, but tough.  :-)  We
can't exactly drop a pointer to a struct block_device in the trace
buffer, since there's no guarantee it will still be valid when we read
it out.  Dropping in a dev_t is exactly what we want.  It would be
nice though if there was a way to specify a major/minor number as the
filter predicate for the dev_t, and not to have the user generate the
MAJOR/MINOR encoding.  So some way of parsing "MKDEV(8, 4)" as the
input to the filter predicate would probably be a really good thing to
do.

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