linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Bart Van Assche <bvanassche@acm.org>, linux-kernel@vger.kernel.org
Cc: linux-scsi@vger.kernel.org, Hannes Reinecke <hare@suse.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>
Subject: Re: [PATCH 3/3] block: add back command filter modification via sysfs
Date: Fri, 16 Nov 2018 08:00:35 +0100	[thread overview]
Message-ID: <44a2a5d0-1802-e6b0-b6e2-5930eed37e21@redhat.com> (raw)
In-Reply-To: <1542347164.100259.32.camel@acm.org>

On 16/11/18 06:46, Bart Van Assche wrote:
> I do not know any application for which it would be useful to allow some but
> not all of these commands. With the proposed interface however users will
> have to examine all SCSI opcodes and for each opcode they will have to decide
> whether or not it should be allowed. Additionally, for opcodes like 7fh that
> represent multiple commands, users will have to decide whether they want to
> allow all these commands or none. That's why I think that filtering SCSI
> commands based on their CDB is an unfortunate choice. Would it be sufficient
> for the use cases you are looking at to group SCSI commands as follows and to
> enable/disable these commands per group:
> * SCSI command that read information from the medium (e.g. READ) or from the
>   controller (e.g. READ CAPACITY).
> * SCSI commands that modify information on the medium (e.g. WRITE).
> * SCSI commands that modify controller settings (e.g. MODE SELECT or SET
>   TARGET PORT GROUPS).

And also:

* all SCSI commands (e.g. write microcode, vendor specific commands).

It would.  However, it would be impossible to do this without making the
filter depend on the SCSI device type.  This has been rejected in 2012.

Paolo

  reply	other threads:[~2018-11-16  7:00 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-10 16:35 [PATCH 0/3] SG_IO command filtering via sysfs Paolo Bonzini
2018-11-10 16:35 ` [PATCH 1/3] block: add back queue-private command filter Paolo Bonzini
2018-11-10 16:35 ` [PATCH 2/3] scsi: create an all-one filter for scanners Paolo Bonzini
2018-11-10 16:35 ` [PATCH 3/3] block: add back command filter modification via sysfs Paolo Bonzini
2018-11-16  5:46   ` Bart Van Assche
2018-11-16  7:00     ` Paolo Bonzini [this message]
2018-11-16 14:42       ` Bart Van Assche
2018-11-10 19:05 ` [PATCH 0/3] SG_IO command filtering " Theodore Y. Ts'o
2018-11-11 13:26   ` Paolo Bonzini
2018-11-11 14:14     ` Theodore Y. Ts'o
2018-11-16  0:26       ` Paolo Bonzini
2018-11-16  0:37         ` Bart Van Assche
2018-11-16  7:01           ` Paolo Bonzini
2018-11-16 17:35             ` Theodore Y. Ts'o
2018-11-11 13:14 ` Christoph Hellwig
2018-11-11 13:42   ` Theodore Y. Ts'o
2018-11-12  8:20     ` Christoph Hellwig
2018-11-12 10:17       ` Paolo Bonzini
2018-11-16  9:32         ` Christoph Hellwig
2018-11-16  9:45           ` Paolo Bonzini
2018-11-16  9:48             ` Christoph Hellwig
2018-11-16 17:43             ` Theodore Y. Ts'o
2018-11-16 18:17               ` Bart Van Assche
2018-11-16 21:08                 ` Paolo Bonzini
  -- strict thread matches above, loose matches on Subject: below --
2012-09-12 11:25 [PATCH 0/3] block: add queue-private command filter, editable " Paolo Bonzini
2012-09-12 11:25 ` [PATCH 3/3] block: add back command filter modification " Paolo Bonzini
2012-09-12 12:38   ` Alan Cox
2012-09-12 12:41   ` Alan Cox
2012-09-12 12:56     ` Paolo Bonzini
2012-09-12 11:23 [PATCH 0/3] block: add queue-private command filter, editable " Paolo Bonzini
2012-09-12 11:23 ` [PATCH 3/3] block: add back command filter modification " 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=44a2a5d0-1802-e6b0-b6e2-5930eed37e21@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=bvanassche@acm.org \
    --cc=hare@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.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).