linux-kernel - Re: PATCH 1/3] blktrace: support per-partition tracing

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: <20090414094326.GB3558@elte.hu>
Date:	Tue, 14 Apr 2009 11:43:26 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Li Zefan <lizf@...fujitsu.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Tom Zanussi <tzanussi@...il.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Theodore Ts'o <tytso@....edu>, Shawn Du <duyuyang@...il.com>,
	LKML <linux-kernel@...r.kernel.org>, linux-btrace@...r.kernel.org
Subject: Re: PATCH 1/3] blktrace: support per-partition tracing


* Li Zefan <lizf@...fujitsu.com> wrote:

> >>> Lets note that this approach still has the (long existing) 
> >>> limitation that only one device can be block-traced at a time.
> >>>
> >> No, both userspace blktrace and ftrace-plugin trace can trace
> >> more than one device at a time.
> >>
> >>  # btrace /dev/sda /dev/dm-0
> >>
> >> or
> >>
> >>  # echo 1 > /sys/block/sda/trace/enable
> >>  # echo 1 > /sys/block/dm-0/trace/enable
> > 
> > When they are independent - but not multiple partitions at a time:
> 
> The only way to trace multipl partitions is to trace the whole 
> sda, or set trace/start_lsa and trace/end_lsa properly.

... or, once we have the filtering engine upgraded, to use 
or-connected filters:

 # [mockup example]

 sector >= 20000 && sector <= 30000
 ||
 sector >= 50000 && sector <= 60000

Note that users dont have to care about these expressions - they 
could get auto-added when tracing is enabled for a partition.

Such type of more complex compound filters are possible already - 
what we dont have is comparison operators (right now we only have == 
and !=), nor built-in convenience support for dev_t.

Another variant would be:

 dev == sda1
 ||
 dev == sda3

type of compound filters - achieving the same goal as the sector 
based filter.

> >  [root@...ebaran ~]# echo 1 > /sys/block/sda/sda1/trace/enable 
> >  [root@...ebaran ~]# echo 1 > /sys/block/sda/sda2/trace/enable 
> >  -bash: echo: write error: Device or resource busy
> 
> That's because struct blk_trace is attached to struct 
> request_queue, sda1 and sda2 share the same rq:
> 
>   # echo 1 > /sys/block/sda/sda1/trace/enable 
>   # cat /sys/block/sda/sda1/trace/enable 
>   1
>   # cat /sys/block/sda/sda2/trace/enable 
>   1

yes - i'm just pointing out the limitation. It's no big issue 
currently - most of the actual tracing happens on specific 
devices/partitions. (Perhaps 'whole system blk tracing' is a common 
pattern though.)

I'm just pointing out that this is a beauty wart, and that it will 
be mostly addressed when we go to TRACE_EVENT() based tracepoints in 
blktrace :-)

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