linux/drivers/scsi, branch v3.19

Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

2015-02-05T19:17:15Z

Pull SCSI fixes from James Bottomley: "This patch set is fixing two serious problems which have turned up late in the release cycle. The first fixes a problem with 4k sector disks where the transfer length (amount of data sent to the disk) was getting increased every time the disk was revalidated leading to potential for overflows. The other is a regression oops fix for some of our last merge window code" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: sd: Fix max transfer length for 4k disks scsi: fix device handler detach oops

sd: Fix max transfer length for 4k disks

2015-02-02T12:46:29Z

The following patch fixes an issue observed with 4k sector disks where the max_hw_sectors attribute was getting set too large in sd_revalidate_disk. Since sdkp->max_xfer_blocks is in units of SCSI logical blocks and queue_max_hw_sectors is in units of 512 byte blocks, on a 4k sector disk, every time we went through sd_revalidate_disk, we were taking the current value of queue_max_hw_sectors and increasing it by a factor of 8. Fix this by only shifting sdkp->max_xfer_blocks. Cc: stable@vger.kernel.org Signed-off-by: Brian King Reviewed-by: Paolo Bonzini Reviewed-by: Martin K. Petersen Signed-off-by: Christoph Hellwig

scsi: fix device handler detach oops

2015-02-02T12:45:28Z

This fixes a regression caused by commit 1d5203 ("scsi: handle more device handler setup/teardown in common code"). The bug is that the alua detach() callout will try to access the sddev->scsi_dh_data, but we have already set it to NULL. This patch moves the clearing of that field to after detach() is called. Signed-off-by: Mike Christie Signed-off-by: Christoph Hellwig

Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux

2015-01-27T17:02:09Z

Pull one more module fix from Rusty Russell: "SCSI was using module_refcount() to figure out when the module was unloading: this broke with new atomic refcounting. The code is still suspicious, but this solves the WARN_ON()" * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: scsi: always increment reference count

scsi: always increment reference count

2015-01-23T04:12:16Z

James reported: > After e513cc1 module: Remove stop_machine from module unloading, > module_refcount() is returning (unsigned long)-1 when called from within > a routine that runs in module_exit. This is confusing the scsi device > put code which is coded to detect a module_refcount() of zero for > running within a module exit routine and not try to do another > module_put. The fix is to restore the original behaviour of > module_refcount() and return zero if we're running inside an exit > routine. The correct fix is to turn try_module_get() into __module_get(), and always do the module_put(). Acked-by: James Bottomley Signed-off-by: Rusty Russell

scsi_debug: test always evaluates to false, || should be used instead

2015-01-22T16:50:52Z

cppcheck found the following issue: (warning) Logical conjunction always evaluates to false: alloc_len < 4 && alloc_len > 65535. ..the test should be instead: if (alloc_len < 4 || alloc_len > 65536) This error was introduced by recent commit 38d5c8336e60bf6e53a1da9 ("scsi_debug: add Report supported opcodes+tmfs; Compare and write") Signed-off-by: Colin Ian King Acked-by: Douglas Gilbert Signed-off-by: Christoph Hellwig

scsi: Avoid crashing if device uses DIX but adapter does not support it

2015-01-20T08:04:21Z

This can happen if a multipathed device uses DIX and another path is added via an adapter that does not support it. Multipath should not allow this path to be added, but we should not depend upon that to avoid crashing. Signed-off-by: Ewan D. Milne Reviewed-by: Martin K. Petersen Signed-off-by: Christoph Hellwig

scsi_debug: use atomic allocation in resp_rsup_opcodes

2015-01-20T08:04:21Z

resp_rsup_opcodes() may get called from atomic context and would need to use GFP_ATOMIC for allocations: [ 1237.913419] BUG: sleeping function called from invalid context at mm/slub.c:1262 [ 1237.914865] in_atomic(): 1, irqs_disabled(): 0, pid: 7556, name: trinity-c311 [ 1237.916142] 3 locks held by trinity-c311/7556: [ 1237.916981] #0: (sb_writers#5){.+.+.+}, at: do_readv_writev (include/linux/fs.h:2346 fs/read_write.c:844) [ 1237.919713] #1: (&of->mutex){+.+.+.}, at: kernfs_fop_write (fs/kernfs/file.c:297) [ 1237.922626] Mutex: counter: -1 owner: trinity-c311 [ 1237.924044] #2: (s_active#51){.+.+.+}, at: kernfs_fop_write (fs/kernfs/file.c:297) [ 1237.925960] Preemption disabled blk_execute_rq_nowait (block/blk-exec.c:95) [ 1237.927416] [ 1237.927680] CPU: 24 PID: 7556 Comm: trinity-c311 Not tainted 3.19.0-rc4-next-20150116-sasha-00054-g4ad498c-dirty #1744 [ 1237.929603] ffff8804fc9d8000 ffff8804d9bc3548 ffffffff9d439fb2 0000000000000000 [ 1237.931097] 0000000000000000 ffff8804d9bc3588 ffffffff9a18389a ffff8804d9bc3598 [ 1237.932466] ffffffff9a1b1715 ffffffffa15935d8 ffffffff9e6f8cb1 00000000000004ee [ 1237.933984] Call Trace: [ 1237.934434] dump_stack (lib/dump_stack.c:52) [ 1237.935323] ___might_sleep (kernel/sched/core.c:7339) [ 1237.936259] ? mark_held_locks (kernel/locking/lockdep.c:2549) [ 1237.937293] __might_sleep (kernel/sched/core.c:7305) [ 1237.938272] __kmalloc (mm/slub.c:1262 mm/slub.c:2419 mm/slub.c:2491 mm/slub.c:3291) [ 1237.939137] ? resp_rsup_opcodes (include/linux/slab.h:435 drivers/scsi/scsi_debug.c:1689) [ 1237.940173] resp_rsup_opcodes (include/linux/slab.h:435 drivers/scsi/scsi_debug.c:1689) [ 1237.941211] ? add_host_store (drivers/scsi/scsi_debug.c:1584) [ 1237.942261] scsi_debug_queuecommand (drivers/scsi/scsi_debug.c:5276) [ 1237.943404] ? blk_rq_map_sg (block/blk-merge.c:254) [ 1237.944398] ? scsi_init_sgtable (drivers/scsi/scsi_lib.c:1095) [ 1237.945402] sdebug_queuecommand_lock_or_not (drivers/scsi/scsi_debug.c:5300) [ 1237.946735] scsi_dispatch_cmd (drivers/scsi/scsi_lib.c:1706) [ 1237.947720] scsi_queue_rq (drivers/scsi/scsi_lib.c:1996) [ 1237.948687] __blk_mq_run_hw_queue (block/blk-mq.c:816) [ 1237.949796] blk_mq_run_hw_queue (block/blk-mq.c:896) [ 1237.950903] ? _raw_spin_unlock (./arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:154 kernel/locking/spinlock.c:183) [ 1237.951862] blk_mq_insert_request (block/blk-mq.c:1037) [ 1237.952876] blk_execute_rq_nowait (block/blk-exec.c:95) [ 1237.953981] ? lockdep_init_map (kernel/locking/lockdep.c:3034) [ 1237.954967] blk_execute_rq (block/blk-exec.c:131) [ 1237.955929] ? blk_rq_bio_prep (block/blk-core.c:2835) [ 1237.956913] scsi_execute (drivers/scsi/scsi_lib.c:252) [ 1237.957821] scsi_execute_req_flags (drivers/scsi/scsi_lib.c:281) [ 1237.958968] scsi_report_opcode (drivers/scsi/scsi.c:956) [ 1237.960009] sd_revalidate_disk (drivers/scsi/sd.c:2707 drivers/scsi/sd.c:2792) [ 1237.961139] revalidate_disk (fs/block_dev.c:1081) [ 1237.962223] sd_rescan (drivers/scsi/sd.c:1532) [ 1237.963142] scsi_rescan_device (drivers/scsi/scsi_scan.c:1579) [ 1237.964165] store_rescan_field (drivers/scsi/scsi_sysfs.c:672) [ 1237.965254] dev_attr_store (drivers/base/core.c:138) [ 1237.966319] sysfs_kf_write (fs/sysfs/file.c:131) [ 1237.967289] kernfs_fop_write (fs/kernfs/file.c:311) [ 1237.968274] do_readv_writev (fs/read_write.c:722 fs/read_write.c:854) [ 1237.969295] ? __acct_update_integrals (kernel/tsacct.c:145) [ 1237.970452] ? kernfs_fop_open (fs/kernfs/file.c:271) [ 1237.971505] ? _raw_spin_unlock (./arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:154 kernel/locking/spinlock.c:183) [ 1237.972512] ? context_tracking_user_exit (include/linux/vtime.h:89 include/linux/jump_label.h:114 include/trace/events/context_tracking.h:47 kernel/context_tracking.c:140) [ 1237.973668] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2578 kernel/locking/lockdep.c:2625) [ 1237.974882] ? trace_hardirqs_on (kernel/locking/lockdep.c:2633) [ 1237.975850] vfs_writev (fs/read_write.c:893) [ 1237.976691] SyS_writev (fs/read_write.c:926 fs/read_write.c:917) [ 1237.977538] system_call_fastpath (arch/x86/kernel/entry_64.S:423) Signed-off-by: Sasha Levin Acked-by: Douglas Gilbert Signed-off-by: Christoph Hellwig

ipr: wait for aborted command responses

2015-01-19T09:46:20Z

Fixes a race condition in abort handling that was injected when multiple interrupt support was added. When only a single interrupt is present, the adapter guarantees it will send responses for aborted commands prior to the response for the abort command itself. With multiple interrupts, these responses generally come back on different interrupts, so we need to ensure the abort thread waits until the aborted command is complete so we don't perform a double completion. This race condition was being hit frequently in environments which were triggering command timeouts, which was resulting in a double completion causing a kernel oops. Cc: Signed-off-by: Brian King Reviewed-by: Wendy Xiong Tested-by: Wendy Xiong Signed-off-by: Christoph Hellwig

scsi: ->queue_rq can't sleep

2015-01-09T14:43:01Z

The blk-mq ->queue_rq method is always called from process context, but might have preemption disabled. This means we still always have to use GFP_ATOMIC for memory allocations, and thus need to revert part of commit 3c356bde1 ("scsi: stop passing a gfp_mask argument down the command setup path"). Signed-off-by: Christoph Hellwig Reported-by: Sasha Levin Reviewed-by: Bart Van Assche Tested-by: Alexei Starovoitov