linux-kernel - Re: setting up CDB filters in udev (was Re: [PATCH v2 0/3] block: add queue-private command filter, editable via sysfs)

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: <20121102175350.GB27843@mtj.dyndns.org>
Date:	Fri, 2 Nov 2012 10:53:50 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	Ric Wheeler <rwheeler@...hat.com>,
	Petr Matousek <pmatouse@...hat.com>,
	Kay Sievers <kay@...hat.com>, Jens Axboe <axboe@...nel.dk>,
	linux-kernel@...r.kernel.org,
	"James E.J. Bottomley" <James.Bottomley@...senPartnership.com>
Subject: Re: setting up CDB filters in udev (was Re: [PATCH v2 0/3] block:
 add queue-private command filter, editable via sysfs)

Hello, Paolo.

On Fri, Nov 02, 2012 at 06:49:43PM +0100, Paolo Bonzini wrote:
> > No rule is really absolute.  To me, it seems the suggested in-kernel
> > per-device command code filter is both too big for the given problem
> 
> Is it?  150 lines of code?  The per-class filters would share the first
> two patches with this series, add a long list of commands to filter, and
> the ioctl would be on top of that.

It's not really about the lines of code.  It adds a new userland
visible interface.  As for the "long" list of commands, it depends on
how you write it but even if it's textually long it's still very
simple in terms of actual complexity.

> > while being too limited for much beyond that.
> 
> What are the use cases beyond these?  AFAIK these were the first two in
> ten years or so...

If this is such a cold area, why do we want do anything other than the
simplest possible?

> > So, if we can get away
> > with adding an ioctl, I personally think that would be a better
> > approach.
> 
> I would really prefer to get a green light from Jens/James for per-class
> filters in the kernel (which are worth a few hundred lines of data)
> before implementing that.

Sure, Jens, James?  Guys, come on.

Thanks.

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