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: <20081103180845.GC32603@ghostprotocols.net>
Date:	Mon, 3 Nov 2008 16:08:45 -0200
From:	Arnaldo Carvalho de Melo <acme@...hat.com>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH][v3] blktrace: conversion to tracepoints

Em Mon, Nov 03, 2008 at 06:22:45PM +0100, Jens Axboe escreveu:
> On Mon, Nov 03 2008, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Oct 30, 2008 at 12:11:45PM +0100, Jens Axboe escreveu:
> > > On Thu, Oct 30 2008, Arnaldo Carvalho de Melo wrote:
> > > > Yes, I tested it, run 'btrace /dev/sda' several times, while doing a
> > > > 45 GB backup using rsync over NFS, etc. So it should have exercised the
> > > > tracepoints use and repeated registrater/unregister cycles.
> > > 
> > > Awesome, just wanted to know what level of testing you had done (from
> > > "none" to "doesn't crash" to "actually works"), so thanks for that.
> > 
> > Jens,
> > 
> > 	Now I'm working on the marker glue code for systemtap to use
> > these tracepoints and I noticed that one important piece of information
> > is not available unless one first uses blk_trace_ioctl to fill in
> > request_queue->blk_trace, that is request_queue->blk_trace->dev, i.e.
> > the device associated with the request_queue.
> > 
> > 	Is there a way to, from the request_queue, get the dev? I guess
> > not, as if there would be you wouldn't have added it to struct
> > blk_trace...
> > 
> > 	Would it be sane to add get struct block_device->bd_dev dev_t
> > info into struct request_queue at sd_probe time or most probably at some
> > more suitable routine in the device/disk registration sequence of
> > events?
> 
> You can't do that, the queue is nothing more than a transport. There's
> no sane way to map from a queue to a device, since it's not given that
> there will be a 1:1 mapping even. So no go there, sorry.

No problem, its just that users such as systemtap will need to be
provided a way to ask for the mapping to be established just like
blktrace does today, except that no relay channel will be setup, etc.
Then, at tracepoint time, if the mapping was established, i.e. if
q->blk_trace is non NULL, we will then be able to look at
q->blk_trace->dev.

I'll come up with a patch for comments.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ