From: Tejun Heo <tj@kernel.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, axboe@kernel.dk,
linux-scsi@vger.kernel.org,
"James E.J. Bottomley" <JBottomley@parallels.com>
Subject: Re: [PATCH] sg_io: allow UNMAP and WRITE SAME without CAP_SYS_RAWIO
Date: Tue, 11 Sep 2012 11:29:04 -0700 [thread overview]
Message-ID: <20120911182904.GS7677@google.com> (raw)
In-Reply-To: <504F7B65.9090603@redhat.com>
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.
> > 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
next prev parent reply other threads:[~2012-09-11 18:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-20 16:30 [PATCH] sg_io: allow UNMAP and WRITE SAME without CAP_SYS_RAWIO Paolo Bonzini
2012-08-01 15:53 ` Paolo Bonzini
2012-08-28 11:04 ` Paolo Bonzini
2012-09-05 14:41 ` [Ping^3] " Paolo Bonzini
2012-09-05 20:18 ` Ric Wheeler
2012-09-06 6:31 ` Paolo Bonzini
2012-09-06 11:31 ` Ric Wheeler
2012-09-06 11:49 ` Paolo Bonzini
2012-09-06 12:08 ` Ric Wheeler
2012-09-06 12:36 ` Paolo Bonzini
2012-09-06 14:20 ` Lukáš Czerner
2012-09-11 16:59 ` Tejun Heo
2012-09-11 17:56 ` Paolo Bonzini
2012-09-11 18:29 ` Tejun Heo [this message]
2012-09-11 18:54 ` Paolo Bonzini
2012-09-11 19:13 ` Tejun Heo
2012-09-11 19:24 ` Paolo Bonzini
2012-09-11 20:01 ` Tejun Heo
2012-09-11 21:50 ` Paolo Bonzini
2012-09-11 22:02 ` Tejun Heo
2012-09-11 22:10 ` Paolo Bonzini
2012-09-11 22:13 ` Tejun Heo
2012-09-12 8:05 ` James Bottomley
2012-09-12 8:18 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120911182904.GS7677@google.com \
--to=tj@kernel.org \
--cc=JBottomley@parallels.com \
--cc=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=pbonzini@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).