Re: [GIT PULL] target fixes for v4.11-rc3

On Sat, 2017-03-18 at 19:08 -0700, Nicholas A. Bellinger wrote: > Hello Linus, > > Here are the target-pending fixes for v4.11-rc3 code. Please go ahead > and pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master > > The bulk of the changes are in qla2xxx

[GIT PULL] target fixes for v4.11-rc3

Hello Linus, Here are the target-pending fixes for v4.11-rc3 code. Please go ahead and pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master The bulk of the changes are in qla2xxx target driver code to address various issues found during Cavium/QLogic's

Re: [PATCH v4 00/14] qla2xxx: Bug Fixes and updates for target.

On Wed, 2017-03-15 at 09:48 -0700, Himanshu Madhani wrote: > Hi Nic, > > Please consider this series for inclusion in target-pending. > > This series contains following changes. > > o Fix for the deadlock because of inconsistent lock usage reported by Bart. > o Added patch to submit

Re: [PATCH v2] scsi_sysfs: fix hang when removing scsi device

On Sat, 2017-03-18 at 12:17 +0100, Hannes Reinecke wrote: > On 03/17/2017 12:00 AM, Bart Van Assche wrote: > > I hadn't seen this crash before kernel v4.11-rc1 but with kernel v4.11-rc1 > > and later I see it if I let the srp-test scripts run for a few minutes. The > > patch I used to disable

Re: [PATCH 0/3] Unblock SCSI devices even if the LLD is being unloaded

On Fri, 2017-03-17 at 16:40 +, Bart Van Assche wrote: > On Fri, 2017-03-17 at 05:54 -0700, James Bottomley wrote: > > So it's better to use the module without a reference in place and > > take the risk that it may exit and release its code area while > > we're calling it? > > Hello James, >

Re: [PATCH 0/3] Unblock SCSI devices even if the LLD is being unloaded

On Sat, 2017-03-18 at 07:44 -0500, James Bottomley wrote: > On Fri, 2017-03-17 at 16:40 +, Bart Van Assche wrote: > > Does your comment mean that you think there is a scenario in which > > scsi_target_block() or scsi_target_unblock() can be called while the > > text area of a SCSI LLD is

Re: [PATCH 3/3] Ensure that scsi_target_unblock() examines all devices

-if-the-LLD-is-being-unloaded/20170318-214016 base: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next reproduce: make htmldocs All warnings (new ones prefixed by >>): drivers/scsi/scsi.c:669: warning: No description found for parameter 'sdev' drivers/scsi/scsi

Re: [PATCH 2/3] Introduce starget_for_all_devices() and shost_for_all_devices()

-if-the-LLD-is-being-unloaded/20170318-214016 base: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next reproduce: make htmldocs All warnings (new ones prefixed by >>): >> drivers/scsi/scsi.c:669: warning: No description found for parameter 'sdev' drivers/scs

Re: [PATCH 3/3] scsi_dh_alua: Warn if the first argument of alua_rtpg_queue() is NULL

On 03/18/2017 01:02 AM, Bart Van Assche wrote: > Callers must provide a valid port group to alua_rtpg_queue(). > Issue a kernel warning if that is not the case. > > Signed-off-by: Bart Van Assche > Cc: Hannes Reinecke > Cc: Tang Junhui

Re: [PATCH 2/3] scsi_dh_alua: Ensure that alua_activate() calls the completion function

On 03/18/2017 01:02 AM, Bart Van Assche wrote: > Callers of scsi_dh_activate(), e.g. dm-mpath, assume that this > function either returns an error code or calls the completion > function. Make alua_activate() call the completion function even > if scsi_device_get() fails. > > Signed-off-by: Bart

Re: [PATCH v2] scsi_sysfs: fix hang when removing scsi device

On 03/17/2017 12:00 AM, Bart Van Assche wrote: > On Mon, 2017-03-13 at 14:55 -0700, James Bottomley wrote: >> On Mon, 2017-03-13 at 20:33 +, Bart Van Assche wrote: >>> On Mon, 2017-03-13 at 12:23 -0700, James Bottomley wrote: On Mon, 2017-03-13 at 18:49 +, Bart Van Assche wrote: >

Re: [PATCH 1/3] scsi_dh_alua: Check scsi_device_get() return value

On 03/18/2017 01:02 AM, Bart Van Assche wrote: > Do not queue ALUA work nor call scsi_device_put() if the scsi_device_get() > call fails. This patch fixes the following crash: > > general protection fault: [#1] SMP > RIP: 0010:scsi_device_put+0xb/0x30 > Call Trace: > scsi_disk_put+0x2d/0x40