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]
Date:	Sat, 17 Jan 2009 18:08:04 -0200
From:	Arnaldo Carvalho de Melo <acme@...hat.com>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] ftrace interface for blktrace

Em Sat, Jan 17, 2009 at 08:14:30PM +0100, Jens Axboe escreveu:
> On Sat, Jan 17 2009, Ingo Molnar wrote:
> > 
> > * Arnaldo Carvalho de Melo <acme@...hat.com> wrote:
> > 
> > > Hi Jens,
> > > 
> > > 	The patch below adds a ftrace interface for blktrace, allowing 
> > > people to use it without any required userspace tools, using sysfs to 
> > > setup the act_mask, pid, start_lba, end_lba.
> > 
> > Very nice patch!
> > 
> > Jens, i'm wondering what's your take on this direction is. I think the 
> > consolidation effect is great and the built-in IO tracing capabilities are 
> > very nice.
> 
> I like the current patch, from a quick look. I'll look more soonish
> (monday). I've always liked the concept of being able to mix various
> traces into the same stream, since it makes it MUCH easier to see what
> on earth is going wrong. What I didn't like in the patches Acme did was
> the enable part, I'll need to look into that. Again, from a quick look,
> what is the BKL doing in there?!

I'm just trying to keep locking expectations in the previous, similar
path, in block/ioctl.c, blkdev_ioctl, where we setup q->blk_trace:

        case BLKTRACESTART:
        case BLKTRACESTOP:
        case BLKTRACESETUP:
        case BLKTRACETEARDOWN:
                lock_kernel();
                ret = blk_trace_ioctl(bdev, cmd, (char __user *) arg);
                unlock_kernel();
                break;

So I took the safest path and grabbed the big K lock.
 
> > We can still get the raw events too and do user-space post-processing, 
> > when that is desired - so this does not limit anything that blktrace was 
> > able to do before - it only extends on it.
> > 
> > Is there any particular blktrace feature you can think of that is not 
> > present in the blktrace ftrace plugin?
> 
> Can't answer that yet, I'll give it a more thorough look next week.

Looking forward to that. And will get it split into multiple patches,
hopefully by monday.

- 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