linux-toradex.git/drivers/scsi/device_handler, branch v4.9.16

scsi: scsi_dh_alua: Fix a reference counting bug

2016-11-01T17:32:24+00:00

The code at the end of alua_rtpg_work() is as follows:

	scsi_device_put(sdev);
	kref_put(&pg->kref, release_port_group);

In other words, alua_rtpg_queue() must hold an sdev reference and a pg
reference before queueing rtpg work. If no rtpg work is queued no
additional references should be held when alua_rtpg_queue() returns. If
no rtpg work is queued, ensure that alua_rtpg_queue() only gives up the
sdev reference if that reference was obtained by the same
alua_rtpg_queue() call.

Signed-off-by: Bart Van Assche 
Reported-by: Tang Junhui 
Cc: Hannes Reinecke 
Cc: Tang Junhui 
Cc: 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Martin K. Petersen

scsi: scsi_dh_alua: fix missing kref_put() in alua_rtpg_work()

2016-11-01T17:31:08+00:00

Reference count of pg leaks in alua_rtpg_work() since kref_put() is not
called to decrease the reference count of pg when the condition
pg->rtpg_sdev==NULL satisfied (actually it is easy to satisfy), it would
cause memory of pg leakage.

Signed-off-by: tang.junhui 
Cc: 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Martin K. Petersen

scsi: scsi_dh_alua: Fix memory leak in alua_rtpg()

2016-09-27T00:42:38+00:00

buff should be freed before returning with SCSI_DH_RETRY in alua_rtpg().

Signed-off-by: tang.junhui 
Signed-off-by: Martin K. Petersen

Merge branch 'fixes' into misc

2016-05-18T01:12:50+00:00

scsi_dh_alua: do not fail for unknown VPD identification

2016-05-11T01:31:17+00:00

Not every device will return a useable VPD identification, but still
might support ALUA. Rather than disable ALUA support we should be
allowing the device identification to be empty and attach individual
ALUA device handler to each devices.

[mkp: Fixed typo reported by Bart]

Reported-by: Paul Mackerras 
Signed-off-by: Hannes Reinecke 
Tested-by: Paul Mackerras 
Reviewed-by: Bart Van Assche 
Signed-off-by: Martin K. Petersen

scsi_dh_alua: uninitialized variable in alua_rtpg()

2016-04-30T16:24:50+00:00

It's possible to use "err" without initializing it.  If it happens to be
a 2 which is SCSI_DH_RETRY then that could cause a bug.  Bart Van Assche
pointed out that we should probably re-initialize it for every iteration
through the retry loop.

Signed-off-by: Dan Carpenter 
Reviewed-by: Hannes Reinicke 
Signed-off-by: Martin K. Petersen 
Signed-off-by: James Bottomley

scsi_dh_alua: Declare local functions static

2016-04-15T20:53:19+00:00

This patch avoids that building with W=1 causes gcc to report the
following type of warning:

    no previous prototype for ... [-Wmissing-prototypes]

Signed-off-by: Bart Van Assche 
Reviewed-by: Hannes Reinicke 
Cc: Hannes Reinecke 
Cc: Christoph Hellwig 
Cc: Ewan Milne 
Signed-off-by: Martin K. Petersen

scsi_dh_alua: Fix a recently introduced deadlock

2016-03-30T00:32:02+00:00

While retesting the SRP initiator I ran the command "rmmod mlx4_ib"
while I/O was in progress. That command triggers SCSI device removal
indirectly. Avoid that this action triggers the following deadlock:

=================================
[ INFO: inconsistent lock state ]
4.6.0-rc0-dbg+ #2 Tainted: G           O
---------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
multipathd/484 [HC0[0]:SC0[0]:HE1:SE1] takes:
 (&(&pg->lock)->rlock){+.?...}, at: [] alua_bus_detach+0x52/0xa0 [scsi_dh_alua]
{IN-SOFTIRQ-W} state was registered at:
  [] __lock_acquire+0x7e9/0x1ad0
  [] lock_acquire+0x60/0x80
  [] _raw_spin_lock_irqsave+0x3e/0x60
  [] alua_rtpg_queue+0x41/0x1d0 [scsi_dh_alua]
  [] alua_check+0xe1/0x220 [scsi_dh_alua]
  [] alua_check_sense+0x99/0xb0 [scsi_dh_alua]
  [] scsi_check_sense+0x71/0x3f0
  [] scsi_decide_disposition+0x18b/0x1d0
  [] scsi_softirq_done+0x52/0x140
  [] blk_done_softirq+0x52/0x90
  [] __do_softirq+0x10f/0x230
  [] irq_exit+0xa8/0xb0
  [] do_IRQ+0x65/0x110
  [] ret_from_intr+0x0/0x19
  [] kmem_cache_alloc+0x151/0x190
  [] create_object+0x34/0x2d0
  [] kmemleak_alloc_percpu+0x56/0xd0
  [] pcpu_alloc+0x38d/0x660
  [] __alloc_percpu_gfp+0xd/0x10
  [] __percpu_counter_init+0x55/0xb0
  [] blkg_alloc+0x79/0x230
  [] blkcg_init_queue+0x26/0x1d0
  [] blk_alloc_queue_node+0x27d/0x2e0
  [] dm_create+0x20c/0x570 [dm_mod]
  [] dev_create+0x56/0x2c0 [dm_mod]
  [] ctl_ioctl+0x26e/0x520 [dm_mod]
  [] dm_ctl_ioctl+0xe/0x20 [dm_mod]
  [] do_vfs_ioctl+0x8e/0x660
  [] SyS_ioctl+0x3c/0x70
  [] entry_SYSCALL_64_fastpath+0x1c/0xac
irq event stamp: 4290931
hardirqs last  enabled at (4290931): [ 1662.892772]
[] _raw_spin_unlock_irqrestore+0x31/0x50
hardirqs last disabled at (4290930): [] _raw_spin_lock_irqsave+0x17/0x60
softirqs last  enabled at (4290774): [] __do_softirq+0x1cb/0x230
softirqs last disabled at (4289831): [] irq_exit+0xa8/0xb0

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&(&pg->lock)->rlock);
  
    lock(&(&pg->lock)->rlock);

 *** DEADLOCK ***

2 locks held by multipathd/484:
 #0:  (&bdev->bd_mutex){+.+.+.}, at: [] __blkdev_put+0x33/0x360
 #1:  (sd_ref_mutex){+.+...}, at: [] scsi_disk_put+0x1c/0x40

stack backtrace:
CPU: 6 PID: 484 Comm: multipathd Tainted: G           O    4.6.0-rc0-dbg+ #2
Call Trace:
 [] dump_stack+0x67/0x92
 [] print_usage_bug+0x215/0x240
 [] mark_lock+0x54a/0x610
 [] __lock_acquire+0x845/0x1ad0
 [] lock_acquire+0x60/0x80
 [] _raw_spin_lock+0x33/0x50
 [] alua_bus_detach+0x52/0xa0 [scsi_dh_alua]
 [] scsi_dh_release_device+0x17/0x50
 [] scsi_device_dev_release_usercontext+0x2a/0x120
 [] execute_in_process_context+0x80/0x90
 [] scsi_device_dev_release+0x17/0x20
 [] device_release+0x2d/0x90
 [] kobject_release+0x7a/0x190
 [] kobject_put+0x26/0x50
 [] put_device+0x12/0x20
 [] scsi_device_put+0x26/0x30
 [] scsi_disk_put+0x2d/0x40
 [] sd_release+0x48/0xb0
 [] __blkdev_put+0x29e/0x360
 [] blkdev_put+0x49/0x170
 [] blkdev_close+0x20/0x30
 [] __fput+0xe8/0x1f0
 [] ____fput+0x9/0x10
 [] task_work_run+0x6e/0xa0
 [] exit_to_usermode_loop+0xa9/0xb0
 [] syscall_return_slowpath+0xb0/0xc0
 [] entry_SYSCALL_64_fastpath+0xaa/0xac

Fixes: cb0a168cb6b8 (scsi_dh_alua: update 'access_state' field)
Cc: Hannes Reinecke 
Signed-off-by: Bart Van Assche 
Reviewed-by: Laurence Oberman 
Reviewed-by: Hannes Reinicke 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Ewan Milne 
Signed-off-by: Martin K. Petersen

scsi_dh_alua: uninitialized variable in alua_check_vpd()

2016-03-15T01:04:59+00:00

The pg_updated variable is support to be set to false at the start but
it is uninitialized.

Fixes: cb0a168cb6b8 ('scsi_dh_alua: update 'access_state' field')
Signed-off-by: Dan Carpenter 
Reviewed-by: Hannes Reinicke 
Reviewed-by: Manoj Kumar 
Signed-off-by: Martin K. Petersen

scsi_dh_emc: update 'access_state' field

2016-03-05T22:20:33+00:00

Update the 'access_state' field of the SCSI device whenever the path
state changes.

Signed-off-by: Hannes Reinecke 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen