Re: [PATCH] scsi: qla2xxx: deadlock by configfs_depend_item

Any thoughts on this change? Thanks.

[PATCH v2] scsi: qla2xxx: pci error handler sync

pci_unregister_driver. Then we have to maintain per-pci_dev context with the state of in-flight handlers and the driver structures associated with pci_dev. The contet outlives both the structs and the pci_dev. Signed-off-by: Anatoliy Glagolev --- drivers/scsi/qla2xxx/Makefile| 3

Re: [PATCH] scsi: qla2xxx: disabling pci error handler early

will send a new patch. On Fri, Dec 07, 2018 at 04:00:27PM -0600, Brian King wrote: > On 12/07/2018 01:56 PM, Anatoliy Glagolev wrote: > > qla2x00_disable_board_on_pci_error and pcie error handlers may run > > in parallel. Specifically, I observed qla2xxx_pci_slot_reset running &g

[PATCH] scsi: qla2xxx: disabling pci error handler early

handler crashes. This patch disables pcie error handling early in qla2x00_disable_board_on_pci_error and in other paths that remove those structs. Signed-off-by: Anatoliy Glagolev --- drivers/scsi/qla2xxx/qla_os.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a

[PATCH] scsi: qla2xxx: deadlock by configfs_depend_item

configfs_depend_item from a configfs callback: the call occasionally deadlocks. Thus, removing configfs_depend_item calls does not break anything and fixes the deadlock problem. Signed-off-by: Anatoliy Glagolev --- drivers/scsi/qla2xxx/tcm_qla2xxx.c | 48 +++---

[PATCH] Bsg referencing parent device

00:00:00 2001 From: Anatoliy Glagolev Date: Wed, 16 May 2018 17:03:09 -0600 Subject: [PATCH] Bsg referencing parent device Signed-off-by: Anatoliy Glagolev Bsg holding reference to a parent device may result in a crash if user closes a bsg file handle after the parent device driver has unload

Re: [PATCH] bsg referencing bus driver module

mes's idea of cutting of the bsg layer at fc_bsg_remove time? Thanks. On Thu, Apr 26, 2018 at 06:01:00PM -0600, Anatoliy Glagolev wrote: > Any thoughts on this? Can we really drop a reference from a child device > (bsg_class_device) to a parent device (Scsi_Host) while the child d

Re: [PATCH] bsg referencing bus driver module

a SCSI bus driver (like qla2xxx) itself; it is safe to drop the module reference at that time. >From c744d4fd93578545ad12faa35a3354364793b124 Mon Sep 17 00:00:00 2001 From: Anatoliy Glagolev Date: Wed, 25 Apr 2018 19:16:10 -0600 Subject: [PATCH] bsg referencing parent module Signed-off

Re: [PATCH] bsg referencing bus driver module

Thanks, James. The idea of cutting communications with Scsi_Host at bsg_unregister_queue(..) time and leaving bsg_class_device to its own fate makes a lot of sense, conceptually. But there are implementation issues that are difficult to work around. bsg.c creates bsg_class_device and takes a refer

Re: [PATCH] bsg referencing bus driver module

elf back in "Waiting for scsi_host_template release" discussion. >From df939b80d02bf37b21efaaef8ede86cfd39b0cb8 Mon Sep 17 00:00:00 2001 From: Anatoliy Glagolev Date: Thu, 19 Apr 2018 15:06:06 -0600 Subject: [PATCH] bsg referencing parent module Fixing a bug when bsg layer holds the las

Re: [PATCH] bsg referencing bus driver module

Updated: rebased on recent Linux, cc-ed maintainers per instructions in MAINTAINERS file >From df939b80d02bf37b21efaaef8ede86cfd39b0cb8 Mon Sep 17 00:00:00 2001 From: Anatoliy Glagolev Date: Thu, 19 Apr 2018 15:06:06 -0600 Subject: [PATCH] bsg referencing parent module Fixing a bug when

Re: [PATCH] bsg referencing bus driver module

+linux-block On Tue, Apr 17, 2018 at 1:05 PM, Anatoliy Glagolev wrote: > Description: bsg_release may crash while decrementing reference to the > parent device with the following stack: > > [16834.636216,07] Call Trace: > ... scsi_proc_hostdir_rm >

Re: [PATCH] Waiting for scsi_host_template release

Sent out a new patch with "bsg referencing bus driver module" in subj. On Wed, Apr 11, 2018 at 4:37 PM, Anatoliy Glagolev wrote: > On "what was the actual error": it is deref of an invalid address, not > NULL. Attaching crash dump analysis for the reference. > >

[PATCH] bsg referencing bus driver module

Description: bsg_release may crash while decrementing reference to the parent device with the following stack: [16834.636216,07] Call Trace: ... scsi_proc_hostdir_rm [16834.641944,07] [] scsi_host_dev_release+0x3f/0x130 [16834.647740,07] [] device_release+0x32/0xa0

Re: [PATCH] Waiting for scsi_host_template release

's Scsi_Host-s corresponding to the adapter's ports will stay forever. Let me think more about it; the idea is to intercept open/close at Scsi_Host and increment/decrement module reference at that time. Thanks a lot for the input! On Wed, Apr 11, 2018 at 1:12 PM, James Bottomley wrote:

Re: [PATCH] Waiting for scsi_host_template release

template after a driver calls scsi_remove_host for that Scsi_Host. On Wed, Apr 11, 2018 at 7:39 AM, James Bottomley wrote: > On Wed, 2018-04-11 at 16:11 +0200, Hannes Reinecke wrote: >> On Mon, 9 Apr 2018 23:23:51 -0700 >> Anatoliy Glagolev wrote: >> >> > Description: >&

[PATCH] Waiting for scsi_host_template release

Description: SCSI mid-layer may hold references to Scsi_Host structs when the owning module has already unloaded. Scsi_Host release path touches scsi_host_template struct that is usually allocated in the unloaded module's memory. That results in a crash. To work around the problem, this change impl