Any comments on the new patch (which, I think, addresses the concern
about module being stuck in unloadable state forever; if not, there
would be a leak in the bsg layer)? Or on dropping a reference
to bsg_class_device's parent early before the bsg_class_device
itself is gone, to implement James's
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 device
is still around at fc_bsg_remove time?
If not, please consider a fix with module references. I realized that
the previous version of the fix had a probl
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
On Fri, 2018-04-20 at 16:44 -0600, Anatoliy Glagolev wrote:
>
> > This patch isn't applyable because your mailer has changed all the
> > tabs to spaces.
> >
> > I also think there's no need to do it this way. I think what we
> > need is for fc_bsg_remove() to wait until the bsg queue is
> > dra
> This patch isn't applyable because your mailer has changed all the tabs
> to spaces.
>
> I also think there's no need to do it this way. I think what we need
> is for fc_bsg_remove() to wait until the bsg queue is drained. It does
> look like the author thought this happened otherwise the co
On Thu, 2018-04-19 at 15:10 -0700, Anatoliy Glagolev wrote:
> 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
>
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 bsg laye
+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
> [16834.641944,07]
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
9 matches
Mail list logo