Thread (24 messages) 24 messages, 5 authors, 2012-09-12

Re: [PATCH] sg_io: allow UNMAP and WRITE SAME without CAP_SYS_RAWIO

From: Tejun Heo <tj@kernel.org>
Date: 2012-09-11 18:29:12
Also in: lkml

Hello, Paolo.

On Tue, Sep 11, 2012 at 07:56:53PM +0200, Paolo Bonzini wrote:
Understood; unfortunately, there is another major user of it
(virtualization).  If you are passing "raw" LUNs down to a virtual
machine, there's no possibility at all to use a properly encapsulated
Is there still command filtering issue when you're passing "raw" LUNs
down?
interface and still be able to pass sense data etc. back to the virtual
machine.  And it's only going to grow now that people are starting to
use virtio-scsi.

The set of use cases is so variable that no single filter can accomodate
all of them: high availability people want persistent reservations, NAS
people want trim/discard, but these are just two groups.  Someone is
using a Windows VM to run vendor tools and wants to have access to
vendor-specific commands.

You can tell this last group to use root, but not everyone else who is
already relying on Unix permissions, SELinux and/or device cgroups to
confine their virtual machines.
You listed three - HA w/ persistent reservation, NAS w/ trim/discard
and the third which you said that using root would be fine.  Dunno
much about persistent reservation but I don't see why trim/discard
can't use existing block layer facilities whether from userland or
virtio-scsi?
A generic filter (see
http://article.gmane.org/gmane.linux.kernel/1312326 for a proposal)
would be satisfactory for everyone, but it's also a major undertaking
and so far I've not received a single comment about it.
Maybe I'm just not familiar with the problem space but I really hope
things don't come to that.  It's not like kernel by itself has to
support every single possible use cases.
quoted
So, it wouldn't be a good idea to abuse SG_IO filtering for exposing
trim/discard.  It's something which should be retired or at least
severely restricted in time.  I don't think we want to be developing
new uses of it.

I think trim/discards are fairly easy to abstract and common enough to
justify having properly abstracted interface.  In fact, we already
have block layer interface for it - BLKDISCARD.  If it's lacking,
let's improve that.
I do want to improve the block layer interfaces to avoid that people use
SG_IO.  But unfortunately this is for a completely different use case.
Hmmm?  This was about discard, no?

Thanks.

-- 
tejun
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help