On Wed, Jan 25, 2017 at 08:26:05AM +0100, Hannes Reinecke wrote:
> For any device with an older SCSI revision we might not
> be scanning VPD pages, which results in a wrongly configured
> discard mode if thin provisioned is enabled.
> According to sbc3 any thin provisioned device (ie devices which
For any device with an older SCSI revision we might not
be scanning VPD pages, which results in a wrongly configured
discard mode if thin provisioned is enabled.
According to sbc3 any thin provisioned device (ie devices which
have the LBPME bit set in the output of READ CAPACITY(16)) need
to suppor
On Tue, Jan 24, 2017 at 9:17 PM, Guilherme G. Piccoli
wrote:
> From: Ram Pai
>
> The firmware or device, possibly under a heavy I/O load, can return
> on a partial unaligned boundary. Scsi-ml expects these requests to be
> completed on an alignment boundary. Scsi-ml blindly requeues the I/O
> wit
This patch avoids that sending a WRITE SAME command to the iSCSI
initiator triggers the following:
BUG: unable to handle kernel NULL pointer dereference at 0014
TARGET_CORE[iSCSI]: Expected Transfer Length: 260096 does not match SCSI CDB
Length: 512 for SAM Opcode: 0x41
IP: iscsi_tcp_
On Tue, Jan 24, 2017 at 11:39:51AM -0500, Mike Snitzer wrote:
> Fair enough. Cc'ing Junichi just in case he sees anything we're
> missing.
Thanks, I'll wait for his repsonse before reposting with the few accumulated
changes (including the dm cleanup).
--
To unsubscribe from this list: send the li
On 1/24/17, 9:24 AM, "Bart Van Assche" wrote:
>On 01/19/2017 10:29 PM, Himanshu Madhani wrote:
>> Please consider this updated series for inclusion in target-pending.
>>
>> Changes from v3 --> v4
>>
>> o Fixed warnings reported by smatch tool.
>> o Fixed indentatation warnings reported by smat
On 01/19/2017 10:29 PM, Himanshu Madhani wrote:
> Please consider this updated series for inclusion in target-pending.
>
> Changes from v3 --> v4
>
> o Fixed warnings reported by smatch tool.
> o Fixed indentatation warnings reported by smatch tool.
>
> Changes from v2 --> v3
>
> o Cleaned up s
On Tue, Jan 24 2017 at 9:20am -0500,
Christoph Hellwig wrote:
> On Tue, Jan 24, 2017 at 05:05:39AM -0500, Mike Snitzer wrote:
> > possible and is welcomed cleanup. The only concern I have is that using
> > get_request() for the old request_fn request_queue eliminates the
> > guaranteed availabi
On Tue, 2017-01-24 at 09:09 +0100, h...@lst.de wrote:
> On Tue, Jan 24, 2017 at 12:33:13AM +, Bart Van Assche wrote:
> > Do we perhaps need a check before the above memcpy() call whether or not
> > sense == NULL?
>
> Yes, probably. I didn't think of the case where the caller wouldn't
> pass a
From: Ram Pai
The firmware or device, possibly under a heavy I/O load, can return
on a partial unaligned boundary. Scsi-ml expects these requests to be
completed on an alignment boundary. Scsi-ml blindly requeues the I/O
without checking the alignment boundary of the I/O request for the
remaining
Dear Team,
On Mon, 2017-01-23 at 18:27 +0100, Frans van Berckel wrote:
>
> If someone could dig into trap_64 in cheetah_deferred_handler? I am
> able to install the dbgsym of the linux-image package and set debug
> on.
>
> That will be in the next e-mail if it does what we are looking for.
It l
On Tue, Jan 24, 2017 at 08:06:39AM -0700, Jens Axboe wrote:
> We check for REQ_PREFLUSH | REQ_FUA in so many places though, might not
> be a bad idea to keep the helper but just make it take the opf and fix
> up the other locations too. The fact that PREFLUSH|FUA is the magic to
> check for is some
On Mon, Jan 23 2017, Christoph Hellwig wrote:
> We can't initalize the elevator fields for flushes as flush share space
> in struct request with the elevator data. But currently we can't
> commnicate that a request is a flush through blk_get_request as we
> can only pass READ or WRITE, and the low
Hi Bart,
First of all, sorry for the new bug; I didn't realize the pointer could
be NULL at this scenario.
On 01/23/2017 02:34 PM, Bart Van Assche wrote:
@@ -1624,7 +1627,8 @@ qla2x00_abort_all_cmds(scsi_qla_host_t *vha, int res)
*/
On Tue, Jan 24, 2017 at 05:05:39AM -0500, Mike Snitzer wrote:
> possible and is welcomed cleanup. The only concern I have is that using
> get_request() for the old request_fn request_queue eliminates the
> guaranteed availability of requests to allow for forward progress (on
> path failure or for
On 01/23/2017 04:29 PM, Christoph Hellwig wrote:
> These days we have the proper flags set since request allocation time.
>
> Signed-off-by: Christoph Hellwig
> ---
> block/blk-core.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index fe5cc98..93
On 01/23/2017 04:29 PM, Christoph Hellwig wrote:
> And require all drivers that want to support BLOCK_PC to allocate it
> as the first thing of their private data. To support this the legacy
> IDE and BSG code is switched to set cmd_size on their queues to let
> the block layer allocate the additi
On 01/23/2017 04:29 PM, Christoph Hellwig wrote:
> Rely on the new block layer functionality to allocate additional driver
> specific data behind struct request instead of implementing it in SCSI
> itѕelf.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/scsi/hosts.c | 20 +--
> driver
On 11/03/2016 12:15 AM, Sreekanth Reddy wrote:
On Tue, Nov 1, 2016 at 11:52 PM, Douglas Miller
wrote:
On 10/24/2016 01:54 PM, Sreekanth Reddy wrote:
Observing below kernel panic while creating second raid disk
on LSI SAS3008 HBA card.
[ +0.55] [ cut here ]
[ +0.0
On Mon, Jan 23, 2017 at 08:34:46AM -0800, Bart Van Assche wrote:
> Avoid that issuing a LIP as follows:
>
> find /sys -name 'issue_lip'|while read f; do echo 1 > $f; done
>
> triggers the following:
>
> BUG: unable to handle kernel NULL pointer dereference at (null)
> Call Trace:
> qla2x00_ab
On Mon, Jan 23, 2017 at 08:34:45AM -0800, Bart Van Assche wrote:
> qla2x00_probe_one() allocates IRQs before it initializes rsp_q_map
> so IRQs must be freed even if rsp_q_map allocation did not occur.
> This was detected by kmemleak.
>
> Fixes: 4fa183455988 ("scsi: qla2xxx: Utilize
> pci_alloc_i
On Mon, Jan 23, 2017 at 04:29:14PM +0100, Christoph Hellwig wrote:
> When using the slab allocator we already decide at cache creation time if
> an allocation comes from a GFP_DMA pool using the SLAB_CACHE_DMA flag,
> and there is no point passing the kmalloc-family only GFP_DMA flag to
> kmem_cach
On Mon, Jan 23, 2017 at 03:26:09PM +0530, Chaitra P B wrote:
> Due existence of loop in the IO path our HBA will receive heavy IOs and
> also as driver is not updating the Reply Post Host Index frequently, So
> there will be a high chance that our Firmware unable to find any free entry
> in the Rep
On Mon, Jan 23, 2017 at 03:26:08PM +0530, Chaitra P B wrote:
> Small glitch/degraded performance in Crusader is improved with SAS
> drives by removing unnecessary spinlocks while clearing scsi command
> in drivers internal lookup table.
>
> Signed-off-by: Chaitra P B
> Signed-off-by: Suganath Pra
Sounds ok to me.
---
drivers/scsi/scsi_debug.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index cf04a36..a4456ca 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -125,6 +125,7 @@ static
On Mon, Jan 23, 2017 at 04:29:17PM +0100, Christoph Hellwig wrote:
> Instead do an internal export of __scsi_init_queue for the transport
> classes that export BSG nodes.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn
On 01/23/2017 04:29 PM, Christoph Hellwig wrote:
> Instead do an internal export of __scsi_init_queue for the transport
> classes that export BSG nodes.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/scsi/scsi_lib.c | 19 ---
> drivers/scsi/scsi_transport_fc.c
On 01/23/2017 04:29 PM, Christoph Hellwig wrote:
> There is no need for GFP_DMA allocations of the scsi_cmnd structures
> themselves, all that might be DMAed to or from is the actual payload,
> or the sense buffers.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/scsi/scsi.c | 15 +-
On 01/23/2017 04:29 PM, Christoph Hellwig wrote:
> Currently blk-mq always allocates the sense buffer using normal GFP_KERNEL
> allocation. Refactor the cmd pool code to split the cmd and sense allocation
> and share the code to allocate the sense buffers as well as the sense buffer
> slab caches
On Mon, Jan 23 2017 at 10:29am -0500,
Christoph Hellwig wrote:
> DM already calls blk_mq_alloc_request on the request_queue of the
> underlying device if it is a blk-mq device. But now that we allow drivers
> to allocate additional data and initialize it ahead of time we need to do
> the same fo
On 01/23/2017 04:29 PM, Christoph Hellwig wrote:
> DM already calls blk_mq_alloc_request on the request_queue of the
> underlying device if it is a blk-mq device. But now that we allow drivers
> to allocate additional data and initialize it ahead of time we need to do
> the same for all drivers.
On 01/23/2017 04:29 PM, Christoph Hellwig wrote:
> DM tries to copy a few fields around for BLOCK_PC requests, but given
> that no dm-target ever wires up scsi_cmd_ioctl BLOCK_PC can't actually
> be sent to dm.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/md/dm-rq.c | 16
On 01/23/2017 04:29 PM, Christoph Hellwig wrote:
> This mirrors the blk-mq capabilities to allocate extra drivers-specific
> data behind struct request by setting a cmd_size field, as well as having
> a constructor / destructor for it.
>
> Signed-off-by: Christoph Hellwig
> ---
> block/blk-core.
On Tue, Jan 24, 2017 at 12:33:13AM +, Bart Van Assche wrote:
> Do we perhaps need a check before the above memcpy() call whether or not
> sense == NULL?
Yes, probably. I didn't think of the case where the caller wouldn't
pass a sense buffer. Just curious, what's the callstack that caused
thi
34 matches
Mail list logo
