Il 18/07/2012 15:42, Anthony Liguori ha scritto:
> If you add support for a new command, you need to provide userspace a
> way to disable this command. If you change what gets reported for VPD,
> you need to provide userspace a way to make VPD look like what it did in
> a previous version.
The QE
Il 18/07/2012 21:12, Anthony Liguori ha scritto:
> Is that true for all OSes? Linux may handle things gracefully if UNMAP
> starts throwing errors but that doesn't mean that Windows will.
There is so much USB crap (not just removable, think of ATA-to-USB
enclosures) that they have to deal with pr
Il 19/07/2012 09:28, James Bottomley ha scritto:
>> > INQUIRY responses (at least vendor/product/type) should not change.
> INQUIRY responses often change for arrays because a firmware upgrade
> enables new features and new features have to declare themselves,
> usually in the INQUIRY data. What y
.
Signed-off-by: Paolo Bonzini
---
block/scsi_ioctl.c |3 ++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 260fa80..dd71f18 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -168,13 +168,16 @@ static void
Il 25/07/2012 10:29, Wang Sen ha scritto:
> When using the commands below to write some data to a virtio-scsi LUN of the
> QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash.
>
> # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.)
> # sudo mount /d
Il 25/07/2012 11:22, Boaz Harrosh ha scritto:
>>> >> for_each_sg(table->sgl, sg_elem, table->nents, i)
>>> >> -sg_set_buf(&sg[idx++], sg_virt(sg_elem),
>>> >> sg_elem->length);
>>> >> +sg_set_page(&sg[idx++], sg_page(sg_elem),
>>> >> sg_elem->length,
>>> >
Il 25/07/2012 14:13, Wang Sen ha scritto:
> When using the commands below to write some data to a virtio-scsi LUN of the
> QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash.
>
> # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.)
> # sudo mount
Il 25/07/2012 14:34, Boaz Harrosh ha scritto:
>>> for_each_sg(table->sgl, sg_elem, table->nents, i)
>>> - sg_set_buf(&sg[idx++], sg_virt(sg_elem),
>>> sg_elem->length);
>>> + sg_set_page(&sg[idx++], sg_page(sg_elem),
>>> sg_elem->length,
>>>
Il 25/07/2012 14:47, Boaz Harrosh ha scritto:
>
> NACK-by: Boaz Harrosh
>
>
> Apart from the HighMem pages problem, where in previous sg_set_buf()
> code was the marker copied? It was not because it is not needed because
> the allocation of sg took care of that. For example in 64bit the is no
>
Il 25/07/2012 15:26, Boaz Harrosh ha scritto:
> On 07/25/2012 03:49 PM, Paolo Bonzini wrote:
>
>>
>> Except here the destination array has to be given to virtio, which
>> doesn't (yet) understand chaining. I'm using for_each_sg rather than a
>> simple memc
Il 25/07/2012 15:26, Boaz Harrosh ha scritto:
>>> In SCSI land most LLDs should support chaining just by virtu of using the
>>> for_each_sg macro. That all it takes. Your code above does support it.
>>
>> Yes, it supports it but still has to undo them before passing to virtio.
>>
>> What my LLD doe
Il 25/07/2012 16:36, Boaz Harrosh ha scritto:
>> >
>> > I did test the patch with value-assignment.
>> >
>
> Still you should use the sg_set_page()!!
> 1. It is not allowed to directly manipulate sg entries. One should always
>use the proper accessor. Even if open coding does work and is not
Il 25/07/2012 17:09, Paolo Bonzini ha scritto:
> Il 25/07/2012 16:36, Boaz Harrosh ha scritto:
>>>>
>>>> I did test the patch with value-assignment.
>>>>
>>
>> Still you should use the sg_set_page()!!
>> 1. It is not allowed to directly mani
Il 25/07/2012 17:28, Boaz Harrosh ha scritto:
>> 1) what I get is a scsi_cmnd which contains an N-element scatterlist.
>>
>> 2) virtio-scsi has to build the "packet" that is passed to the hardware
>> (it does not matter that the hardware is virtual). This packet (per
>> virtio-scsi spec) has an N+
Il 25/07/2012 21:16, Boaz Harrosh ha scritto:
> The picture confused me. It looked like the first element is the
> virtio_scsi_cmd_req
> not an sgilist-element that points to the struct's buffer.
>
> In that case then yes your plan of making a two-elements fragment that points
> to the
> origina
Il 25/07/2012 23:04, Boaz Harrosh ha scritto:
>> That not all architectures have ARCH_HAS_SG_CHAIN (though all those I
>> care about do). So I need to go through all architectures and make sure
>> they use for_each_sg, or at least to change ARCH_HAS_SG_CHAIN to a
>> Kconfig define so that dependen
Il 26/07/2012 09:56, Boaz Harrosh ha scritto:
>> > In the meanwhile, we still have a bug to fix, and we need to choose
>> > between Sen Wang's v1 (sg_set_page) or v2 (value assignment). I'm still
>> > leaning more towards v2, if only because I already tested that one myself.
>
> It's your call, y
Il 26/07/2012 10:52, James Bottomley ha scritto:
>> > +static unsigned int virtscsi_get_lun(u8 *lun_bytes)
>> > +{
>> > + unsigned int lun = (lun_bytes[2] << 8) | lun_bytes[3];
>> > + return lun & 16383;
>> > +}
>> > +
> Why are you rolling your own incomplete version of scsilun_to_int here?
Bec
Il 26/07/2012 11:21, James Bottomley ha scritto:
>> > Because scsilun_to_int does not do the AND, so it would have exactly the
>> > same bug I'm fixing.
> It's not a bug ... it's the encoding. All the other devices use this
> too. Ideally we should have switched to 64 bit lun numbers for the
> en
Il 26/07/2012 11:41, James Bottomley ha scritto:
> On Thu, 2012-07-26 at 11:27 +0200, Paolo Bonzini wrote:
>> Il 26/07/2012 11:21, James Bottomley ha scritto:
>>>>> Because scsilun_to_int does not do the AND, so it would have exactly the
>>>>> same bug I&#x
Il 26/07/2012 12:33, James Bottomley ha scritto:
>> > Has it already been considered to modify scsilun_to_int() such that LUN
>> > numbers start at zero even for addressing method 1 ? This is what e.g.
>> > the function scst_unpack_lun() already does. See also
>> > http://scst.svn.sourceforge.net/v
Il 26/07/2012 09:58, Paolo Bonzini ha scritto:
>
>> > Please CC me on the "convert to sg copy-less" patches, It looks interesting
> Sure.
Well, here is the gist of it (note it won't apply on any public tree,
hence no SoB yet). It should be split in multiple ch
irtio-scsi
LUNs, which needs to be rebased.
LUNs above 255 now work for all of scanning, hotplug, hotunplug and
resize.
Thanks,
Paolo
Paolo Bonzini (2):
virtio-scsi: fix LUNs greater than 255
virtio-scsi: support online resizing of disks
drivers/scsi/virtio_scsi
capacity change from 22548578304 to 23622320128
Signed-off-by: Paolo Bonzini
---
drivers/scsi/virtio_scsi.c | 31 ++-
include/linux/virtio_scsi.h |2 ++
2 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi
d with the "flat" format.
Cc:
Signed-off-by: Paolo Bonzini
---
drivers/scsi/virtio_scsi.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index c7030fb..8b6b927 100644
--- a/drivers/scsi/virtio_scsi.
Il 27/07/2012 05:12, Wang Sen ha scritto:
>> > No this code is correct, though you will need to make sure to properly
>> > terminate the destination sg_list.
> Yes, the terminate marker in the destination list is set when initialization.
> sg_set_page would not break this marker because it saved bo
Il 27/07/2012 08:27, Rusty Russell ha scritto:
>> > +int virtqueue_add_buf_sg(struct virtqueue *_vq,
>> > + struct scatterlist *sg_out,
>> > + unsigned int out,
>> > + struct scatterlist *sg_in,
>> > + unsigned int in,
>> > +
Il 30/07/2012 01:50, Rusty Russell ha scritto:
>> Also, being the first user of chained scatterlist doesn't exactly give
>> me warm fuzzies.
>
> We're far from the first user: they've been in the kernel for well over
> 7 years. They were introduced for the block layer, but they tended to
> ignore
EMU would not crash any more.
>
> Cc: # 3.4: 4fe74b1: [SCSI] virtio-scsi: SCSI driver
> Signed-off-by: Wang Sen
Acked-by: Paolo Bonzini
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Il 31/07/2012 22:52, Eric Northup ha scritto:
> It seems to me like this is not the way that virtio devices are supposed
> to behave - if a guest splits a virtio_scsi_cmd_req or _resp across a
> page boundary, then this code won't work.
Buffers can cover several pages. Of course, data buffers hav
Il 20/07/2012 18:30, Paolo Bonzini ha scritto:
> These commands cannot be issued right now without giving CAP_SYS_RAWIO to
> the process who wishes to send them. These commands can be useful also to
> non-privileged programs who have access to the block devices. For example
> a vir
tscsi_kick_event(struct virtio_scsi *vscsi,
> struct scatterlist sg;
> unsigned long flags;
>
> - sg_set_buf(&sg, &event_node->event, sizeof(struct virtio_scsi_event));
> + sg_init_one(&sg, &event_node->event, sizeof(struct virtio_scsi_e
Il 01/08/2012 17:53, Paolo Bonzini ha scritto:
> Il 20/07/2012 18:30, Paolo Bonzini ha scritto:
>> These commands cannot be issued right now without giving CAP_SYS_RAWIO to
>> the process who wishes to send them. These commands can be useful also to
>> non-privileged progra
ues/detail?id=37.
Alternatively you can just set the affinity manually in /proc.
Rusty, can you please give your Acked-by to the first two patches?
Jason Wang (2):
virtio-ring: move queue_index to vring_virtqueue
virtio: introduce an API to set affinity for a virtqueue
Paolo Bonzini (3):
v
affinities
requested
Signed-off-by: Jason Wang
Signed-off-by: Paolo Bonzini
---
drivers/virtio/virtio_pci.c | 46 +
include/linux/virtio_config.h | 21 ++
2 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/drivers/virtio
From: Jason Wang
Instead of storing the queue index in transport-specific virtio structs,
this patch moves them to vring_virtqueue and introduces an helper to get
the value. This lets drivers simplify their management and tracing of
virtqueues.
Signed-off-by: Jason Wang
Signed-off-by: Paolo
paths.
Signed-off-by: Paolo Bonzini
---
drivers/scsi/virtio_scsi.c | 23 +++
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 595af1a..62fec04 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi
This will be needed soon in order to retrieve the per-target
struct.
Signed-off-by: Paolo Bonzini
---
drivers/scsi/virtio_scsi.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 62fec04
, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
Signe
James,
here are three important bugfixes for virtio-scsi. All three have been
on the list for a while, I'm grouping them in this post to ease your
processing.
Two of them are also marked for stable branches.
Paolo
Paolo Bonzini (1):
virtio-scsi: fix LUNs greater than 255
Richard W.M.
From: Richard W.M. Jones
The sg struct for events is used without being initialized. This
triggers a BUG_ON if CONFIG_DEBUG_SG is defined.
This was reported at https://bugzilla.redhat.com/show_bug.cgi?id=847548.
Signed-off-by: Richard W.M. Jones
Signed-off-by: Paolo Bonzini
---
drivers
Il 28/08/2012 16:07, Sasha Levin ha scritto:
>> > - num_targets = sh->max_id;
>> > - for (i = 0; i < num_targets; i++) {
>> > - kfree(vscsi->tgt[i]);
>> > - vscsi->tgt[i] = NULL;
>> > + if (vscsi->tgt) {
>> > + num_targets = sh->max_id;
>> > + for (i = 0; i <
the last entry of the source sg_list is copied to
the the last entry in destination list.
Cc: Stable kernel # 3.4: 4fe74b1: [SCSI] virtio-scsi:
SCSI driver
Signed-off-by: Wang Sen
Signed-off-by: Paolo Bonzini
---
drivers/scsi/virtio_scsi.c |2 +-
1 files changed, 1 insertions(+), 1 deleti
d with the "flat" format.
Cc: Stable kernel # 3.4: 4fe74b1: [SCSI] virtio-scsi:
SCSI driver
Signed-off-by: Paolo Bonzini
---
drivers/scsi/virtio_scsi.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_
Il 30/08/2012 16:53, Michael S. Tsirkin ha scritto:
>> > this series adds multiqueue support to the virtio-scsi driver, based
>> > on Jason Wang's work on virtio-net. It uses a simple queue steering
>> > algorithm that expects one queue per CPU. LUNs in the same target always
>> > use the same qu
Il 04/09/2012 04:21, Nicholas A. Bellinger ha scritto:
>> @@ -112,6 +118,9 @@ static void virtscsi_complete_cmd(struct virtio_scsi
>> *vscsi, void *buf)
>> struct virtio_scsi_cmd *cmd = buf;
>> struct scsi_cmnd *sc = cmd->sc;
>> struct virtio_scsi_cmd_resp *resp = &cmd->resp.cmd;
>>
Il 04/09/2012 10:46, Michael S. Tsirkin ha scritto:
+static int virtscsi_queuecommand_multi(struct Scsi_Host *sh,
+ struct scsi_cmnd *sc)
+{
+ struct virtio_scsi *vscsi = shost_priv(sh);
+ struct virtio_scsi_target_state *tgt = vscsi->tgt[s
Il 04/09/2012 13:09, Michael S. Tsirkin ha scritto:
>> > queuecommand on CPU #0 queuecommand #2 on CPU #1
>> > --
>> > atomic_inc_return(...) == 1
>> >atomic_inc_return(...) == 2
>> >
Il 04/09/2012 15:35, Michael S. Tsirkin ha scritto:
> I see. I guess you can rewrite this as:
> atomic_inc
> if (atomic_read() == 1)
> which is a bit cheaper, and make the fact
> that you do not need increment and return to be atomic,
> explicit.
It seems more complicated to me for hardly any rea
ts the driver optimize the IRQ affinity for the
>> > virtqueues (each virtqueue's affinity is set to the CPU that "owns"
>> > the queue).
>> >
>> > Signed-off-by: Paolo Bonzini
> I guess an alternative is a per-target vq.
> Is the reason
Il 04/09/2012 16:19, Michael S. Tsirkin ha scritto:
> > > Also - some kind of comment explaining why a similar race can not happen
> > > with this lock in place would be nice: I see why this specific race can
> > > not trigger but since lock is dropped later before you submit command, I
> > > have
Il 04/09/2012 16:21, Michael S. Tsirkin ha scritto:
> > One reason is that, even though in practice I expect roughly the same
> > number of targets and VCPUs, hotplug means the number of targets is
> > difficult to predict and is usually fixed to 256.
> >
> > The other reason is that per-target vq
Il 04/09/2012 16:47, Michael S. Tsirkin ha scritto:
>> > static void virtscsi_init_vq(struct virtio_scsi_vq *virtscsi_vq,
>> > - struct virtqueue *vq)
>> > + struct virtqueue *vq, bool affinity)
>> > {
>> >spin_lock_init(&virtscsi_vq->vq_lock);
>> >
Il 04/09/2012 22:11, Nicholas A. Bellinger ha scritto:
>>> As tgt->tgt_lock is taken in virtscsi_queuecommand_multi() before the
>>> atomic_inc_return(tgt->reqs) check, it seems like using atomic_dec() w/o
>>> smp_mb__after_atomic_dec or tgt_lock access here is not using atomic.h
>>> accessors prop
Il 28/08/2012 13:04, Paolo Bonzini ha scritto:
> Il 01/08/2012 17:53, Paolo Bonzini ha scritto:
>> Il 20/07/2012 18:30, Paolo Bonzini ha scritto:
>>> These commands cannot be issued right now without giving CAP_SYS_RAWIO to
>>> the process who wishes to send them. T
Il 05/09/2012 22:18, Ric Wheeler ha scritto:
>>
>
> Hi Paolo,
>
> Both of these commands are destructive. WRITE_SAME (if done without the
> discard bits set) can also take a very long time to be destructive and
> tie up the storage.
FORMAT_UNIT has the same characteristics and yet it is allowed
Il 06/09/2012 13:31, Ric Wheeler ha scritto:
>>> Both of these commands are destructive. WRITE_SAME (if done without the
>>> discard bits set) can also take a very long time to be destructive and
>>> tie up the storage.
>>
>> FORMAT_UNIT has the same characteristics and yet it is allowed (btw, I
>>
Il 06/09/2012 14:08, Ric Wheeler ha scritto:
>> According to the standard, the translation layer can write a
>> user-provided pattern to every sector in the disk. It's an optional
>> feature and libata doesn't do that, but it is still possible.
>
> It is not possible today with our stack though,
Il 11/09/2012 18:59, Tejun Heo ha scritto:
> FWIW, I don't think this is the right way to expose functionality
> which needs management in terms of access control, interpretation
> (stacking drivers) and serving concurrent users. SG_IO filtering was
> mostly for cd/dvd burning and other removeable
Il 11/09/2012 20:29, Tejun Heo ha scritto:> 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
>&g
Il 11/09/2012 21:13, Tejun Heo ha scritto:
> Hello, Paolo.
>
> On Tue, Sep 11, 2012 at 08:54:03PM +0200, Paolo Bonzini wrote:
>>> On Tue, Sep 11, 2012 at 07:56:53PM +0200, Paolo Bonzini wrote:
>>>> Understood; unfortunately, there is another major user of it
>
[Al: you can jump down to "One problem:"]
Il 11/09/2012 22:01, Tejun Heo ha scritto:
> Hello, Paolo.
>
> On Tue, Sep 11, 2012 at 09:24:32PM +0200, Paolo Bonzini wrote:
>>> Couldn't it intercept some of them - e.g. RWs and discards?
>>> What
Il 12/09/2012 00:02, Tejun Heo ha scritto:
> SG_IO itself is a bypassing interface. It bypasses most of block
> layer and the kernel doesn't have any idea (apart from the adhoc
> filtering) about what's going on.
That's very much the point. The guest must have free reins.
You asked "Could being
Il 12/09/2012 10:05, James Bottomley ha scritto:
> This is why the whole filter thing was mutable via sysfs. That way the
> admin could set this up per device. It sounds like this is what you
> want to fix, rather than opening up more holes in an already leaky
> security apparatus.
It is, thanks
meanwhile, this patch series provides the sysfs knob. It is a
tweaked revert of commit 018e044 (block: get rid of queue-private command
filter, 2009-06-26).
Paolo Bonzini (3):
block: add back queue-private command filter
scsi: create an all-zero filter for scanners
block: add back command filter
ecial filtering is desired.
This is a partial (and massaged) revert of commit 018e044 (block: get
rid of queue-private command filter, 2009-06-26).
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini
---
block/blk-sysfs.c |2 ++
block/bsg.c|2 +-
block/scsi_io
Using /dev/sg for scanners is blocked from unprivileged users. Reimplement
this using customizable command filters, so that the sysfs knobs will work
in this case too.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini
---
drivers/scsi/scsi_scan.c |6 +-
drivers/scsi/sg.c
anyway never really
enabled, the different API is not a problem.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini
---
Documentation/block/queue-sysfs.txt | 16 ++
block/Kconfig | 10
block/blk-sysfs.c | 41 ++
block
Il 12/09/2012 14:41, Alan Cox ha scritto:
>> > + if (!q->cmd_filter) {
>> > + q->cmd_filter = kmalloc(sizeof(struct blk_cmd_filter),
>> > + GFP_KERNEL);
>> > + blk_set_cmd_filter_defaults(q->cmd_filter);
>> > + }
>> > +
> This also needs CAP_SYS_
v1->v2: add OOM and capability checks
Paolo Bonzini (3):
block: add back queue-private command filter
scsi: create an all-zero filter for scanners
block: add back command filter modification via sysfs
Documentation/block/queue-sysfs.txt | 16 +
block/Kcon
anyway never enabled
(they were always #if 0-ed), the different API is not a problem.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini
---
v2->v3: OOM and capability check [Alan Cox]
Documentation/block/queue-sysfs.txt | 16 ++
block/Kconfig |
Using /dev/sg for scanners is blocked from unprivileged users. Reimplement
this using customizable command filters, so that the sysfs knobs will work
in this case too.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini
---
v1->v2: OOM check [Alan Cox]
ecial filtering is desired.
This is a partial (and massaged) revert of commit 018e044 (block: get
rid of queue-private command filter, 2009-06-26).
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini
---
block/blk-sysfs.c |2 ++
block/bsg.c|2 +-
block/scsi_io
Il 26/07/2012 15:28, Paolo Bonzini ha scritto:
> James,
>
> patch 1 fixes scanning of LUNs whose number is greater than 255. QEMU
> passes a max_lun of 16383 (because it uses SAM numbering) but in Linux
> it must become 32768 (because LUNs above 255 are "relocated"
Il 20/08/2012 16:05, Paolo Bonzini ha scritto:
> Il 20/08/2012 16:04, Richard W.M. Jones ha scritto:
>> From: "Richard W.M. Jones"
>>
>> The sg struct is used without being initialized.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=847
Il 01/10/2012 15:18, Richard W.M. Jones ha scritto:
> On Mon, Oct 01, 2012 at 03:13:01PM +0200, Paolo Bonzini wrote:
>> Il 20/08/2012 16:05, Paolo Bonzini ha scritto:
>>> Il 20/08/2012 16:04, Richard W.M. Jones ha scritto:
>>>> From: "Richard W.M. Jones"
Il 02/10/2012 10:18, James Bottomley ha scritto:
> On Mon, 2012-10-01 at 15:11 +0200, Paolo Bonzini wrote:
>> Il 26/07/2012 15:28, Paolo Bonzini ha scritto:
>>> James,
>>>
>>> patch 1 fixes scanning of LUNs whose number is greater than 255. QEMU
>>> p
James, here is a resend of the three pending patches for
virtio-scsi, with the bugfix first.
Thanks,
Paolo
Paolo Bonzini (2):
virtio-scsi: fix LUNs greater than 255
virtio-scsi: support online resizing of disks
Richard W.M. Jones (1):
virtio-scsi: initialize scatterlist structure
From: Richard W.M. Jones
The sg struct is used without being initialized, which breaks
when CONFIG_DEBUG_SG is enabled.
Cc: sta...@vger.kernel.org
Signed-off-by: Richard W.M. Jones
Signed-off-by: Paolo Bonzini
---
drivers/scsi/virtio_scsi.c |2 +-
1 files changed, 1 insertions(+), 1
capacity change from 22548578304 to 23622320128
Signed-off-by: Paolo Bonzini
---
drivers/scsi/virtio_scsi.c | 31 ++-
include/linux/virtio_scsi.h |2 ++
2 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi
d with the "flat" format.
Signed-off-by: Paolo Bonzini
---
drivers/scsi/virtio_scsi.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 7554d78..a7cf726 100644
--- a/drivers/scsi/virtio_scsi.
Il 25/09/2012 17:30, Paolo Bonzini ha scritto:
> The set of use cases for SG_IO is quite variable that no single filter can
> accomodate all of them. The current filter is tailored very much to
> CD burning, and includes many MMC-specific commands that may have
> other meanings
> > In one use case, the administrator then needs the ability to configure
> > devices easily, for example to be much more restrictive on non-MMC
> > devices. It must be done with the same tools it uses for other
> > aspects of the policy---which will be a combination of DAC (Unix
> > permissions
queue=7459,
> util=88.41%
>
>
> Wanlong Gao (5):
> virtio-scsi: remove the useless assignment
> virtio-scsi: remove the needless variable gfp_mask
> virtio-scsi: use pr_err instead of printk
> virtio-scsi: create a separate work queue for virtio-scsi
> virtio-scsi: ti
fore tgt->tgt_lock while invoking
> the calls to virtio_ring.c:virtqueue_add_buf() and friends.
>
> This bug was originally introduced in v3.5-rc7 code with:
>
> commit 2bd37f0fde99cbf8b78fb55f1128e8c3a63cf1da
> Author: Paolo Bonzini
> Date: Wed Jun 13 16:56:34 201
else
> + mempool_free(cmd, virtscsi_cmd_pool);
>
> out:
> return ret;
>
Acked-by: Paolo Bonzini
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Il 09/11/2012 20:31, Nicholas A. Bellinger ha scritto:
>> That's done on purpose. After you do virtqueue_add_buf, you don't need
>> the sg list anymore, nor the lock that protects it. The cover letter is
>> at https://lkml.org/lkml/2012/6/13/295 and had this text:
>>
>> This series reorganizes
Il 12/11/2012 12:33, James Bottomley ha scritto:
> On Fri, 2012-11-09 at 11:08 -0500, Jason J. Herne wrote:
>> diff --git a/drivers/usb/storage/scsiglue.c
>> b/drivers/usb/storage/scsiglue.c
>> index 13b8bcd..6ff785e 100644
>> --- a/drivers/usb/storage/scsiglue.c
>> +++ b/drivers/usb/storage/scsigl
Il 12/11/2012 16:10, James Bottomley ha scritto:
>> Actually it only turns it on for large capacity drives, as said in the
>> comment. sdp->force_read_16 only matters for >2TB drives:
>
> If you follow the discussion, we'll need to turn it on for some drives
> regardless of size.
Even if the tw
NACKed).
Ok for 3.8?
v2->v3: change bitmap filter to boolean
Paolo Bonzini (2):
sg_io: pass request_queue to blk_verify_command
sg_io: introduce unpriv_sgio queue flag
block/blk-sysfs.c | 32
block/bsg.c|2 +-
block/scsi_ioctl.c |
the CAP_SYS_RAWIO capability anymore, and will also not be
able to send SCSI commands to a partition (which would affect the full
disk).
Cc: linux-scsi@vger.kernel.org
Cc: Alan Cox
Cc: James Bottomley
Cc: Jens Axboe
Cc: Ric Wheeler
Cc: Tejun Heo
Signed-off-by: Paolo Bonzini
---
v2->
Adjust the blk_verify_command function to let it look at per-queue
data. This will be done in the next patch.
Cc: linux-scsi@vger.kernel.org
Cc: Alan Cox
Cc: James Bottomley
Cc: Jens Axboe
Cc: Ric Wheeler
Cc: Tejun Heo
Signed-off-by: Paolo Bonzini
---
v2->v3: separated from &qu
Il 14/11/2012 01:54, Jason J. Herne ha scritto:
> blk_queue_physical_block_size(sdp->request_queue,
> sdkp->physical_block_size);
> sdkp->device->sector_size = sector_size;
> +
> + /* Use read/write(16) for > 2TB disks */
> + sdp->use_16_for_r
Il 15/11/2012 20:23, Nicholas A. Bellinger ha scritto:
>>> > >
>>> > > This patch adds a new max_write_same_len device attribute for use with
>>> > > WRITE_SAME w/ UNMAP=0 backend emulation.
>>> > >
>>> > > Also, update block limits VPD emulation code in spc_emulate_evpd_b0() to
>>> > > set the d
Il 15/11/2012 21:01, Elliott, Robert (Server Storage) ha scritto:
> WRITE SAME always has a payload, regardless of the UNMAP bit value.
>
> For WRITE SAME with UNMAP=0, it's extremely important; that's how
> what to write is specified.
>
> For WRITE SAME with UNMAP=1, the device server is require
On 09/11/2014 17:57, Ming Lei wrote:
> Since virtio_scsi has supported multi virtqueue already,
> it is natural to map virtque to hw-queue of blk-mq.
>
> Cc: Paolo Bonzini
> Signed-off-by: Ming Lei
> ---
> drivers/scsi/virtio_scsi.c | 154
> -
D_LBP_WS16);
> else if (sdkp->lbpws10)
> sd_config_discard(sdkp, SD_LBP_WS10);
> + else if (sdkp->lbpu && sdkp->max_unmap_blocks)
> + sd_config_discard(sdkp, SD_LBP_UNMAP)
On 10/11/2014 17:05, Christoph Hellwig wrote:
>
> a) there is no multiath support for it, and we simply can't break existing
> setups that use.
> b) there is no support for I/O schedulers at all. This might be okay
> for virtio-scsi, where in general you have a host scheduler, but for
On 15/11/2014 04:47, Ming Lei wrote:
> Since virtio_scsi has supported multi virtqueue already,
> it is natural to map the virtque to hw-queue of blk-mq.
>
> Cc: Paolo Bonzini
> Signed-off-by: Ming Lei
> ---
> V1:
> - support non-mq too
>
> dri
> --- a/drivers/scsi/esp_scsi.h
> +++ b/drivers/scsi/esp_scsi.h
> @@ -1,4 +1,4 @@
> -/* esp_scsi.h: Defines and structures for the ESP drier.
> +/* esp_scsi.h: Defines and structures for the ESP driver.
> *
> * Copyright (C) 2007 David S. Miller (da...@davemloft.net)
> */
>
301 - 400 of 428 matches
Mail list logo
