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

From: Tejun Heo
Date: Tue Sep 11 2012 - 14:29:05 EST

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

> 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

> A generic filter (see
> 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.

> > 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?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at