feature.
>
> Steffen Maier (2):
> scsi: core: fix missing .cleanup_rq for SCSI hosts without request
> batching
> scsi: core: fix dh and multipathing for SCSI hosts without request
> batching
>
> drivers/scsi/scsi_lib.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Reviewed-by: Paolo Bonzini
On 25/07/19 19:02, Steffen Maier wrote:
>
> 9e5470fe2d61 ("scsi: virtio_scsi: implement request batching")
> 8930a6c20791 ("scsi: core: add support for request batching")
>
> REBOOT into kernel with above commits reverted and now multipath
> assembly works again:
Can you try applying only this f
ffers)
> added to the tmf.
>
> This fixes the problem by leaving cmd->sc zeroed out, which makes
> virtscsi_kick_cmd() add the tmf to the control vq without any payload.
Indeed, all that the completion routine needs is cmd->comp, which is set
directly in virtscsi_tmf.
Review
On 16/11/18 19:17, Bart Van Assche wrote:
> On Fri, 2018-11-16 at 12:43 -0500, Theodore Y. Ts'o wrote:
>> I'd argue that a purpose-built eBPF access control facility is
>> superior to the security_file_ioctl() LSM hook because it can make
>> available to the authorization function access to the cac
On 16/11/18 10:32, Christoph Hellwig wrote:
> On Mon, Nov 12, 2018 at 11:17:29AM +0100, Paolo Bonzini wrote:
>>> Well, that's what we have the security_file_ioctl() LSM hook for so that
>>> your security model can arbitrate access to ioctls.
>>
>> Doesn't
On 16/11/18 01:37, Bart Van Assche wrote:
> All user space interfaces in the Linux kernel for storage that I'm familiar
> with not only allow configuration of parameters but also make it easy to
> query which parameters have been configured. The existing sysfs and configfs
> interfaces demonstrate
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 sh
On 11/11/2018 15:14, Theodore Y. Ts'o wrote:
> On Sun, Nov 11, 2018 at 02:26:45PM +0100, Paolo Bonzini wrote:
>>
>> I'm not very eBPF savvy, the question I have is: what kind of
>> information about the running process is available in an eBPF program?
>> F
On 12/11/2018 09:20, Christoph Hellwig wrote:
> On Sun, Nov 11, 2018 at 08:42:42AM -0500, Theodore Y. Ts'o wrote:
>> It really depends on the security model being used on a particular
>> system. I can easily imagine scenarios where userspace is allowed
>> full access to the device with respect to
On 10/11/2018 20:05, Theodore Y. Ts'o wrote:
> I wonder if a better way of adding SG_IO command filtering is via
> eBPF? We are currently carrying a inside Google a patch which allows
> a specific of SCSI commands to non-root processes --- if the process
> belonged to a particular Unix group id.
>
ecial filtering is desired.
This is a revert of commit 018e044 ("block: get rid of queue-private
command filter", 2009-06-26), though with many changes.
Cc: linux-scsi@vger.kernel.org
Cc: Hannes Reinecke
Cc: Martin K. Petersen
Cc: James Bottomley
Signed-off-by: Paolo Bonzini
---
bl
API", 2015-10-21,
Linux 4.4). These require CAP_SYS_ADMIN, which is the same capability
that is needed to *grant* access to PR commands via the SG_IO filter.
So, here is the 2018 version of these patches. Please review! :)
Paolo
Paolo Bonzini (3):
block: add back queue-private command fi
anyway never really
enabled, the different userspace API is not a problem.
Cc: linux-scsi@vger.kernel.org
Cc: Hannes Reinecke
Cc: Martin K. Petersen
Cc: James Bottomley
Suggested-by: James Bottomley
Signed-off-by: Paolo Bonzini
---
Documentation/block/queue-sysfs.txt | 19 ++
block/Kconfig
Any command is allowed for scanners when /dev/sg is used.
Reimplement this using customizable command filters, so that the
sysfs knobs will work in this case, too.
Cc: linux-scsi@vger.kernel.org
Cc: Hannes Reinecke
Cc: Martin K. Petersen
Cc: James Bottomley
Signed-off-by: Paolo Bonzini
e if the hw queue hasn't online
> CPUs.
>
> Fix this issue by forcing to use blk_mq.
>
> BTW, I have been used virtio-scsi(scsi_mq) for several years, and it has
> been quite stable, so it shouldn't cause extra risk.
I think that's ok now that we have I/O sched
On 11/08/2017 19:23, Michael S. Tsirkin wrote:
> On Fri, Aug 11, 2017 at 04:09:26PM +0200, Paolo Bonzini wrote:
>> On 10/08/2017 23:41, Michael S. Tsirkin wrote:
>>>>> Then we probably should fail probe if vq size is too small.
>>>> What does this mean?
On 10/08/2017 23:41, Michael S. Tsirkin wrote:
>>> Then we probably should fail probe if vq size is too small.
>> What does this mean?
>
> We must prevent driver from submitting s/g lists > vq size to device.
What is the rationale for the limit? It makes no sense if indirect
descriptors are avai
t; be configured from the qemu command line.
>
> Thanks Paolo Bonzini, Christoph Hellwig.
>
> Signed-off-by: Richard W.M. Jones
> ---
> drivers/scsi/virtio_scsi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/virtio_scsi.c
t; be configured from the qemu command line.
You can clear .can_queue from the templates. Otherwise looks good.
Paolo
> Thanks Paolo Bonzini, Christoph Hellwig.
>
> Signed-off-by: Richard W.M. Jones
> ---
> drivers/scsi/virtio_scsi.c | 2 ++
> 1 file changed, 2 insertions(+
On 10/08/2017 18:40, Richard W.M. Jones wrote:
> If using indirect descriptors, you can make the total_sg as large as
> you want. If not, BUG is too serious because the function later
> returns -ENOSPC.
>
> Thanks Paolo Bonzini, Christoph Hellwig.
>
> Signed-off-b
On 10/08/2017 17:40, Richard W.M. Jones wrote:
> OK this is looking a bit better now.
>
> With scsi-mq enabled: 175 disks
> virtqueue_size=64: 318 disks *
> virtqueue_size=16: 775 disks *
> With scsi-mq disabled: 1755 disks
> * = new results
On 10/08/2017 16:16, Richard W.M. Jones wrote:
> On Thu, Aug 10, 2017 at 02:53:58PM +0200, Paolo Bonzini wrote:
>> can_queue and cmd_per_lun are different. can_queue should be set to the
>> value of vq->vring.num where vq is the command virtqueue (the first one
>> is okay
On 10/08/2017 14:22, Richard W.M. Jones wrote:
> On Wed, Aug 09, 2017 at 06:50:10PM +0200, Paolo Bonzini wrote:
>> On 09/08/2017 18:01, Christoph Hellwig wrote:
>>> On Mon, Aug 07, 2017 at 03:07:48PM +0200, Paolo Bonzini wrote:
>>>> can_queue should depen
On 09/08/2017 18:01, Christoph Hellwig wrote:
> On Mon, Aug 07, 2017 at 03:07:48PM +0200, Paolo Bonzini wrote:
>> can_queue should depend on the virtqueue size, which unfortunately can
>> vary for each virtio-scsi device in theory. The virtqueue size is
>> retrieved by dr
On 07/08/2017 14:27, Richard W.M. Jones wrote:
> Also I noticed this code in virtio_scsi.c:
>
> cmd_per_lun = virtscsi_config_get(vdev, cmd_per_lun) ?: 1;
> shost->cmd_per_lun = min_t(u32, cmd_per_lun, shost->can_queue);
>
> but setting cmd_per_lun (as a qemu virtio-scsi-pci param
On 05/08/2017 17:51, Richard W.M. Jones wrote:
> On Sat, Aug 05, 2017 at 03:39:54PM +0200, Christoph Hellwig wrote:
>> For now can you apply this testing patch to the guest kernel?
>>
>> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
>> index 9be211d68b15..0cbe2c882e1c 100644
Multi-queue virtio-scsi uses a different scsi_host_template struct.
Add the .device_alloc field there, too.
Fixes: 25d1d50e23275e141e3a3fe06c25a99f4c4bf4e0
Cc: sta...@vger.kernel.org
Cc: David Gibson
Signed-off-by: Paolo Bonzini
---
drivers/scsi/virtio_scsi.c | 1 +
1 file changed, 1 insertion
mley"
Cc: "Martin K. Petersen"
Cc: Hannes Reinecke
Cc: linux-scsi@vger.kernel.org
Cc: sta...@vger.kernel.org
Signed-off-by: Paolo Bonzini
---
drivers/scsi/virtio_scsi.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/sc
an the target
>
> s/controller something/controller or something/ ?
Acked-by: Paolo Bonzini
with this change.
Paolo
On 05/04/2017 19:21, Christoph Hellwig wrote:
> +static ssize_t
> +zeroing_mode_store(struct device *dev, struct device_attribute *attr,
> +const char *buf, size_t count)
> +{
> + struct scsi_disk *sdkp = to_scsi_disk(dev);
> +
> + if (!capable(CAP_SYS_ADMIN))
> +
On 29/03/2017 18:28, Bart Van Assche wrote:
> On Wed, 2017-03-29 at 16:51 +0200, Paolo Bonzini wrote:
>> On 28/03/2017 20:50, Bart Van Assche wrote:
>>> This means that just like the start and end of a discard must be aligned on
>>> a
>>> discard_granularit
On 23/03/2017 23:53, Lars Ellenberg wrote:
> Thin does not claim to zero data on discard. which is ok, and correct,
> because it only punches holes on full chunks (or whatever you call
> them), and leaves the rest in the mapping tree as is.
>
> And that behaviour would prevent DRBD from exposin
On 28/03/2017 18:48, Bart Van Assche wrote:
>> +if (rq->cmd_flags & REQ_UNMAP) {
>> +switch (sdkp->provisioning_mode) {
>> +case SD_LBP_WS16:
>> +return sd_setup_write_same16_cmnd(cmd, true);
>> +case SD_LBP_WS10:
>> +
On 28/03/2017 19:00, Bart Van Assche wrote:
> On Thu, 2017-03-23 at 10:33 -0400, Christoph Hellwig wrote:
>> Now that we use the proper REQ_OP_WRITE_ZEROES operation everywhere we can
>> kill this hack.
>>
>> [ ... ]
>>
>> diff --git a/Documentation/ABI/testing/sysfs-block
>> b/Documentation/ABI
On 28/03/2017 20:50, Bart Van Assche wrote:
>
> This means that just like the start and end of a discard must be aligned on a
> discard_granularity boundary, WRITE SAME commands with the UNMAP bit set must
> also respect that granularity. I think this means that either
> __blkdev_issue_zeroout()
- Original Message -
> From: "Michael S. Tsirkin"
> To: "Fam Zheng"
> Cc: linux-ker...@vger.kernel.org, "Paolo Bonzini" ,
> linux-scsi@vger.kernel.org, "James E.J.
> Bottomley" , "Jason Wang" ,
> "M
On 16/01/2017 18:26, Fam Zheng wrote:
>> Is the endianness correct for big-endian host here?
>
> I think so. The fc_host sysfs uses u64 to represent port_name and node_name,
> this patch does the same, so using virtio_* helpers for these fields should
> handle the endianness correctly.
I was sus
> How it this supposed to work?
> You do export the WWPN/WWNN of the associated host to the guest (nb:
> will get interesting for non NPIV setups ...), but virtio scsi will
> still do a LUN remapping.
> IE the LUNs you see on the host will be different from the LUNs
> presented to the guest.
This
On 16/01/2017 17:04, Fam Zheng wrote:
> + node_name = virtio_cread64(vdev,
> + offsetof(struct virtio_scsi_config, primary_wwnn));
> + port_name = virtio_cread64(vdev,
> + offsetof(struct virtio_scsi_config, primary_wwpn));
> + }
On 08/12/2016 00:31, Tyrel Datwyler wrote:
> The first byte of each CRQ entry is used to indicate whether an entry is
> a valid response or free for the VIOS to use. After processing a
> response the driver sets the valid byte to zero to indicate the entry is
> now free to be reused. Add a memory
} else
> + } else {
> + unsigned int flags = FOLL_TOUCH | FOLL_HWPOISON;
> +
> + if (write_fault)
> + flags |= FOLL_WRITE;
> +
> npages = __get_user_pages_unlocked(current, current->mm, addr,
> 1,
> -write_fault, 0, page,
> -FOLL_TOUCH|FOLL_HWPOISON);
> +page, flags);
> + }
> if (npages != 1)
> return npages;
>
>
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
scsi *vscsi = shost_priv(sh);
>
> virtscsi_vq_done(vscsi, &vscsi->event_vq, virtscsi_complete_event);
> -};
> +}
>
> /**
> * virtscsi_add_cmd - add a virtio_scsi_cmd to a virtqueue
>
Acked-by: Paolo Bonzini
--
To unsubscribe from this list: send the li
On 06/06/2016 17:47, John Snow wrote:
> > > Various downstreams may have backported the VPD fix to older versions,
> > > we need to be careful not to block those, too ... so targeting the core
> > > behavior seems like the more strictly correct, easily maintainable
> > > solution.
> >
> > I thi
On 06/06/2016 17:41, John Snow wrote:
> On 06/06/2016 11:05 AM, Paolo Bonzini wrote:
>> For ATAPI, you have to blacklist all versions up to 2.2 inclusive.
>>
>> This gives:
>>
>> - QEMU / QEMU CD-ROM / 0.8.(this is IDE and SCSI)
>> - QEMU / QEMU
On 06/06/2016 16:22, Hannes Reinecke wrote:
> So either we dig into what went wrong with qemu 0.8, or we figure out
> from which qemu version things start to behave nicely, and blacklist
> earlier versions.
>
> > > Either way, this patch is wrong.
> >
> > If we can identify which versions work,
On 10/05/2016 19:31, James Bottomley wrote:
> > What about a SPACE ALLOCATION FAILED error or a similar error that
> > can be fixed by administrator actions (or just by a concurrent
> > process doing an UNMAP)? Would a subsequent cache flush cause data
> > loss?
>
> You're now asking about how
On 10/05/2016 16:16, James Bottomley wrote:
> > If "is performed" just means "completes", maybe with an error, the
> > application would have to resubmit write requests and then try to
> > flush the write cache again.
> >
> > I'm not aware of applications that keep acknowledged write data
> >
On 25/09/2015 11:27, Paolo Bonzini wrote:
> This is v3 of the series to provide an "official" sg.h header (and
> scsi_ioctl.h too, though it's basically obsolete) together with the other
> userspace API definitions. The change from v2 to v3 is that defaults
> f
On 02/11/2015 16:05, Mike Snitzer wrote:
> > In any case, if we don't start path activation we should return
> > ENOTCONN, not ENOTTY.
>
> Currently, if we don't start path activation we're returning EIO.
> ENOTCONN is used for when we do start path activation (and ENOTCONN is
> the means for DM
On 02/11/2015 14:56, Hannes Reinecke wrote:
> But then the real question remains:
>
> What is the 'correct' behaviour for ioctls when no path retry
> is active (or when no paths are present)?
>
> Should we start path activation?
> If so, should we wait for path activation to finish, risking ude
On 02/11/2015 08:28, Hannes Reinecke wrote:
>
> With the original code we would need to wait for path activation
> before we would be able to figure out if the ioctl is valid.
> However, the callback to verify the ioctl is sd_ioctl(), which as
> a first step calls scsi_verify_ioctl().
> So my re
On 31/10/2015 23:47, Mike Snitzer wrote:
> Yes, with your commit ec8013be ("dm: do not forward ioctls from logical
> volumes to the underlying device") you added protections to disallow
> issuing ioctls to a partition that could impact the rest of the device.
>
> Given that I can see why you're
On 31/10/2015 19:13, Mike Snitzer wrote:
> > But that's wrong, I think. It's a false positive in
> > scsi_verify_blk_ioctl().
> >
> > If the ioctl is valid when bdev becomes non-NULL (and it will be if
> > ti->len becomes equal to i_size_read(bdev->bd_inode) >> SECTOR_SHIFT),
> > you should not
On 29/10/2015 14:18, Mike Snitzer wrote:
> > 4) dmesg shows that scsi_verify_blk_ioctl() failed for SG_IO (0x2285);
> >it returns -ENOIOCTLCMD, later replaced with -ENOTTY in vfs_ioctl().
> >
> > $ dmesg
> > <...>
> > [] device-mapper: multipath: Failing path 65:144.
> > [] d
roken driver cpqfc", 2005-10-29).
Remove it, just in time for the the tenth anniversary of its demise.
Cc: James Bottomley
Cc: Christoph Hellwig
Cc: linux-scsi@vger.kernel.org
Reviewed-by: Bart Van Assche
Signed-off-by: Paolo Bonzini
---
include/scsi/scsi.h | 6 ++
include/scsi/sc
t they are actually useful for userspace as
well. Add them to the new header.
Cc: James Bottomley
Cc: Christoph Hellwig
Cc: linux-scsi@vger.kernel.org
Cc: Bart Van Assche
Signed-off-by: Paolo Bonzini
---
drivers/scsi/sg.c | 8 +-
include/scsi/scsi_ioctl.h
Some are in scsi.h. Keep them together in preparation for exposing them
in UAPI headers.
Cc: James Bottomley
Cc: Christoph Hellwig
Cc: linux-scsi@vger.kernel.org
Reviewed-by: Bart Van Assche
Signed-off-by: Paolo Bonzini
---
include/scsi/scsi.h | 20
include/scsi
This is v3 of the series to provide an "official" sg.h header (and
scsi_ioctl.h too, though it's basically obsolete) together with the other
userspace API definitions. The change from v2 to v3 is that defaults
for sg.c are not exported in include/uapi/linux/sg.c.
Paolo
2.5.0
--
To unsubscribe f
Signed-off-by: Paolo Bonzini
---
include/scsi/sg.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/scsi/sg.h b/include/scsi/sg.h
index 3afec7032448..370c78c37926 100644
--- a/include/scsi/sg.h
+++ b/include/scsi/sg.h
@@ -207,12 +207,6 @@ typedef struct sg_req_info { /* used by
On 17/09/2015 17:32, Bart Van Assche wrote:
>
>> +
>> +#ifndef __KERNEL__
>> +/* Keep in sync with SG_DEFAULT_TIMEOUT of scsi/sg.h */
>> #define SG_DEFAULT_TIMEOUT(60*HZ) /* HZ == 'jiffies in 1
>> second' */
>> #endif
>
> Is it useful and/or necessary to export this constant ?
scsi_idlun used to be under
"#ifdef __KERNEL__", but they are actually useful for userspace as
well. Add them to the new header.
Signed-off-by: Paolo Bonzini
---
include/scsi/scsi_ioctl.h | 50 +-
include/scsi/sg.h
roken driver cpqfc", 2005-10-29).
Remove it, just in time for the the tenth anniversary of its demise.
Signed-off-by: Paolo Bonzini
---
include/scsi/scsi.h | 6 ++
include/scsi/scsi_ioctl.h | 8
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/include/scsi/scsi.h
These will not be exported by the new linux/sg.h header, and scsi/sg.h will
not have any user API after linux/sg.h is created. Since they have no
user in the kernel, they can be zapped.
Signed-off-by: Paolo Bonzini
---
include/scsi/sg.h | 6 --
1 file changed, 6 deletions(-)
diff --git a
ls in uapi/linux/scsi_ioctl.h, even those
formerly in scsi/scsi.h [requested by hch]
... and reverting to the flat uapi/linux/ structure instead of
creating uapi/linux/scsi/.
Paolo
Paolo Bonzini (4):
scsi: remove old-style type names from sg.h
scsi: cleanup scsi/scsi_ioctl.h
scsi: mov
Some are in scsi/scsi.h. Keep them together in preparation for exposing
them in UAPI headers.
Suggested-by: Christoph Hellwig
Signed-off-by: Paolo Bonzini
---
include/scsi/scsi.h | 20
include/scsi/scsi_ioctl.h | 20
2 files changed, 20
On 16/09/2015 16:23, Christoph Hellwig wrote:
> > I'm trying to cater to the objections that were made to Andy's patch.
> > If you mean the non-UAPI headers, James wanted them to stay in scsi/; if
> > you mean the UAPI headers, Douglas complained about the flat structure
> > of include/linux/.
>
On 16/09/2015 15:39, Christoph Hellwig wrote:
> Hi Paolo,
>
> can you just move them to include/linux/ directly?
I'm trying to cater to the objections that were made to Andy's patch.
If you mean the non-UAPI headers, James wanted them to stay in scsi/; if
you mean the UAPI headers, Douglas comp
Bottomley
Cc: Christoph Hellwig
Cc: Douglas Gilbert
Cc: Linux SCSI List
Signed-off-by: Paolo Bonzini
---
Similar to Andy Grover's patch from last January, though developed
independently. Based on the remarks to Andy's patch, I'm leaving
scsi.h aside (Christop
ost, SHOST_DIX_GUARD_CRC);
> }
> +#endif
>
> err = scsi_add_host(shost, &vdev->dev);
> if (err)
> @@ -1090,7 +1097,9 @@ static struct virtio_device_id id_table[] = {
> static unsigned int features[] = {
> VIRTIO_SCSI_F_HOTPLUG,
> VIRTIO_SCSI_F_
On 23/04/2015 20:10, Christoph Hellwig wrote:
> T10 PI is just another optional feature, LLDDs should work without
> the infrastructure.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/scsi/Kconfig | 1 -
> drivers/scsi/virtio_scsi.c | 11 ++-
> 2 files changed, 10 insertio
sd_revalidate_disk if read capacity failed
> sd: Return -EIO if read capacity failed
>
> block/partition-generic.c | 6 +++---
> drivers/scsi/sd.c | 22 +-
> 2 files changed, 16 insertions(+), 12 deletions(-)
>
Reviewed-by: Paolo Bonzini
Though p
On 05/03/2015 14:37, Paolo Bonzini wrote:
>
>
> On 05/03/2015 14:33, Christoph Hellwig wrote:
>> Any chance to get reviews for this series? Also we should at least
>> expedite this first patch into 4.0-rc as it fixes scanning races
>> in virtio_scsi.
>
>
On 05/03/2015 14:33, Christoph Hellwig wrote:
> Any chance to get reviews for this series? Also we should at least
> expedite this first patch into 4.0-rc as it fixes scanning races
> in virtio_scsi.
I reviewed 1 and 3, but I'm not really qualified for patch 2.
Paolo
> On Mon, Feb 02, 2015 at
struct scsi_driver *drv = to_scsi_driver(dev->driver);
>
> if (drv->rescan)
> drv->rescan(dev);
> module_put(dev->driver->owner);
> }
> + device_unlock(dev);
> }
> EXPORT_SYMBOL(scsi_rescan_devic
fail try_module_get if we're doing SCSI operations
> - * from module exit (like cache flush) */
> - __module_get(sdev->host->hostt->module);
> -
> + goto fail;
> + if (!try_module_get(sdev->host->hostt->module))
> + goto fail_put_device;
>
On 02/02/2015 13:59, Christoph Hellwig wrote:
> On Fri, Jan 30, 2015 at 10:46:17AM +0100, Paolo Bonzini wrote:
>> > Great, we might want to revert that patch in 3.21.
> Is that fix in any tree yet? Seems like I missed it for the scsi
> tree at least. So unless you want it
On 30/01/2015 02:08, Fam Zheng wrote:
> On Fri, 01/30 00:11, Paolo Bonzini wrote:
>>
>>
>> On 29/01/2015 00:00, Christoph Hellwig wrote:
>>> Lock the device embedded in the scsi_device to protect against
>>> concurrent calls to ->remove.
>>>
&
gt;
> This is useful for vhost ANY_LAYOUT support when guests are allowed to
> generate
> incoming virtio request headers combined with subsequent SGL payloads into a
> single iovec.
>
> Cc: Michael S. Tsirkin
> Cc: Paolo Bonzini
> Signed-off-by: Nicholas Bellinger
On 29/01/2015 00:00, Christoph Hellwig wrote:
> Lock the device embedded in the scsi_device to protect against
> concurrent calls to ->remove.
>
> Signed-off-by: Christoph Hellwig
I wonder if this makes this problem: https://lkml.org/lkml/2015/1/5/9 go
away.
Paolo
> ---
> drivers/scsi/scsi_
blk_queue_max_hw_sectors(sdkp->disk->queue, max_xfer);
> set_capacity(disk, sdkp->capacity);
> sd_config_write_same(sdkp);
> _
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to major
alized. With this change, the panic goes
> away.
>
> Signed-off-by: Fam Zheng
Reviewed-by: Paolo Bonzini
> ---
>
> v4: Addressing MST's comments:
> Use ordered workqueue, with WQ_FREEZABLE and WQ_MEM_RECLAIM flags.
> Coding style fixes.
>
> v3: Fix spa
On 07/11/2014 06:08, Martin K. Petersen wrote:
> The whitelist is only meant as a starting point and is by no means
> comprehensive:
>
>- All intel SSD models except for 510
>- Micron M5*
>- Samsung SSDs
>- Seagate SSDs
>
> Signed-off-by: Martin K. Petersen
> ---
> drivers/ata
On 05/12/2014 14:05, Ming Lei wrote:
>
> [ 50.112885] sd 0:0:1:0: [sda] FAILED Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE
> [ 50.113859] sd 0:0:1:0: [sda] Sense Key : Illegal Request [current]
> [ 50.113859] sd 0:0:1:0: [sda] Add. Sense: Invalid field in cdb
> [ 50.113859] sd 0:0:
amp; sdkp->max_unmap_blocks &&
> !sdkp->lbprz)
> + sd_config_discard(sdkp, SD_LBP_UNMAP);
> + else if (sdkp->lbpws)
> sd_config_discard(sdkp, SD_LBP_WS16);
> else if (sdkp->lbpws10)
>
ev, 0);
> + shost->n_io_port = pci_resource_len(pdev, 0);
> + shost->unique_id = shost->io_port;
> + esp->scsi_id_mask = (1 << esp->scsi_id);
> + /* Assume 40MHz clock */
> + esp->cfreq = 4000;
> +
> + pci_set_drvdata(pdev, pep);
> +
> +
rivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
> index bd17516..56f361e 100644
> --- a/drivers/scsi/esp_scsi.c
> +++ b/drivers/scsi/esp_scsi.c
> @@ -1343,6 +1343,8 @@ static int esp_data_bytes_sent(struct esp *esp, struct
> esp_cmd_entry *ent,
> (((unsigned
6 +269,7 @@ struct esp_cmd_entry {
> #define ESP_CMD_FLAG_WRITE 0x01 /* DMA is a write */
> #define ESP_CMD_FLAG_ABORT 0x02 /* being aborted */
> #define ESP_CMD_FLAG_AUTOSENSE 0x04 /* Doing automatic REQUEST_SENSE */
> +#define ESP_CMD_FLAG_RESIDUAL0x08 /* AM53c974 BLAST residual */
>
> u8 tag[2];
> u8 orig_tag[2];
>
Reviewed-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
break;
> diff --git a/drivers/scsi/esp_scsi.h b/drivers/scsi/esp_scsi.h
> index 975d293..27dcaf8 100644
> --- a/drivers/scsi/esp_scsi.h
> +++ b/drivers/scsi/esp_scsi.h
> @@ -478,6 +478,7 @@ struct esp {
> #define ESP_FLAG_WIDE_CAPABLE0x0008
> #define ESP_FLAG_QUICKIRQ_CHECK 0x0010
> #define ESP_FLAG_DISABLE_SYNC0x0020
> +#define ESP_FLAG_USE_FIFO0x0040
>
> u8 select_state;
> #define ESP_SELECT_NONE 0x00 /* Not selecting */
>
Reviewed-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
On 21/11/2014 11:22, Hannes Reinecke wrote:
> On 11/21/2014 11:08 AM, Paolo Bonzini wrote:
>>
>>
>> On 21/11/2014 10:27, Hannes Reinecke wrote:
>>> CONFIG2_FENAB ('feature enable') changed definition between chip
>>> revisions, from 'Latch
On 21/11/2014 11:38, Hannes Reinecke wrote:
>>> esp->msg_out_len = 0;
>>>
>>> *p++ = IDENTIFY(0, lun);
>>> @@ -648,12 +651,21 @@ static void esp_autosense(struct esp *esp, struct
>>> esp_cmd_entry *ent)
>>> esp_write_tgt_sync(esp, tgt);
>>> esp_write_tgt_config3(esp, tgt);
>>>
Oops, hit send too early. A small nit:
On 21/11/2014 10:27, Hannes Reinecke wrote:
> +static void pci_esp_dma_drain(struct esp *esp)
> +{
> + u8 resid;
> + int lim = 1000;
> +
> +
> + if ((esp->sreg & ESP_STAT_PMASK) == ESP_DOP ||
> + (esp->sreg & ESP_STAT_PMASK) == ESP_DIP)
>
On 21/11/2014 10:27, Hannes Reinecke wrote:
> This patch adds a new implementation for the Tekram DC-390T /
> AMD AM53c974 SCSI controller, based on the generic
> esp_scsi infrastructure.
>
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/Kconfig| 18 ++
> drivers/scsi/Makefile |
um esp_rev {
> FAS100A= 0x04,
> FAST = 0x05,
> FASHME = 0x06,
> + PCSCSI = 0x07, /* AM53c974 */
> };
>
> struct esp_cmd_entry {
> @@ -466,6 +480,7 @@ struct esp {
> u8 bursts;
> u8 config1;
> u8 config2;
> + u8 config4;
>
> u8 scsi_id;
> u32 scsi_id_mask;
>
Reviewed-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
On 21/11/2014 10:27, Hannes Reinecke wrote:
> The am53c974 has an design issue where a single byte might be
> left in the SCSI FIFO after a DMA transfer.
> As the handling code is currently untested add a WARN_ON()
> statement here.
>
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/am53c
On 21/11/2014 10:27, Hannes Reinecke wrote:
> CONFIG2_FENAB ('feature enable') changed definition between chip
> revisions, from 'Latch SCSI Phase' to 'Latch SCSI Phase, display
> chip ID upon reset, and enable 24 bit addresses'.
> So only enable it for am53c974 where we know what it's doing.
>
On 21/11/2014 10:27, Hannes Reinecke wrote:
> The am53c974 has a design flaw causing it to throw an
> DMA interrupt whenever a DMA transmission completed,
> even though DMA interrupt reporting is disabled.
> This confuses the esp routines as it would register
> a DMA interrupt whenever a cdb has
On 21/11/2014 10:27, Hannes Reinecke wrote:
> A read to ESP_INTRPT will clear ESP_STATUS and ESP_SSTEP. So read
> all status registers in one go to avoid losing information.
(ESP_STAT_TCNT is actually kept in the status register, it is cleared by
writing TCLO/MID/HI).
Reviewed-by:
esp->sreg, esp->seqreg, esp->sreg2, esp->ireg);
>
> intr_done = 0;
>
> if (esp->ireg & (ESP_INTR_S | ESP_INTR_SATN | ESP_INTR_IC)) {
> - printk("ESP: unexpected IREG %02x\n", esp->ireg);
> + shost_printk(KERN_INFO, esp->host,
&
> EXPORT_SYMBOL(scsi_esp_cmd);
> @@ -1638,6 +1651,8 @@ static int esp_process_event(struct esp *esp)
>
> again:
> write = 0;
> + esp_log_event("process event %d phase %x\n",
> + esp->event, esp->sreg & ESP_STAT_PMASK);
> swi
; #define ESP_DEFAULT_TAGS 16
>
> #define ESP_MAX_TARGET 16
> @@ -445,7 +444,7 @@ struct esp {
> u8 prev_soff;
> u8 prev_stp;
> u8 prev_cfg3;
> - u8 __pad;
&g
1 - 100 of 428 matches
Mail list logo
