Re: [PATCH] scsi_debug: address races following module load

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, May 08, 2021 at 07:07:45PM -0400, Douglas Gilbert wrote:
> When scsi_debug is loaded as a module with many (simulated) hosts,
> targets, and devices (LUs), modprobe can take a long time to return.
> Only a small amount of this time is spent in the scsi_debug_init();
> the rest is other parts of the kernel reacting to to the appearance
> of new storage devices. As soon as scsi_debug_init() has completed
> the user space may call 'rmmod scsi_debug' and this was found to
> cause race problems as outlined here:
>     https://bugzilla.kernel.org/show_bug.cgi?id=212337
> 
> To reliably generate this race a sysfs parameter called rm_all_hosts
> was added and the code was strengthened in this area. The main
> change was to make the count of scsi_debug hosts present an atomic.
> Then it was found that the handling of the existing add_host
> parameter needed the same strengthening. Further:
>    echo -9999 > /sys/bus/pseudo/drivers/scsi_debug/add_host
> has the same effect as rm_all_hosts so rm_all_hosts was not needed.
> 
> To inhibit a race between two invocations of writes to add_host
> a mutex was added.
> 
> The logic to remove (all) hosts is rather crude: it works backwards
> down a linked lists of hosts. Any pending requests are terminated
> with DID_NO_CONNECT as are any new requests. In the case where not
> all hosts are being removed, the ones that remain may have lost
> requests as just outlined. The lowest numbered host (id) hosts will
> remain.
> 
> To distinguish between resets sent by the SCSI mid-level error
> handling and newly introduced devices (LUs), this Unit Attention:
>    power on, reset, or bus reset occurred [0x29,0x0]
> has been subdivided into that UA for the reset case and this new UA:
>    power on occurred [0x29,0x1]
> for the new device (LU) case. This makes debug a little easier to
> follow when it is turned on (e.g. 'echo 0x1 > opts').
> 
> 
> This patch should apply to lk 5.13.0-rc1 due out tomorrow unless some
> other patches have been applied to this driver that I'm unaware of.
> 
> Signed-off-by: Douglas Gilbert <dgilbert@xxxxxxxxxxxx>

This is a lot of changes and it still does not address the issues on
the bugzilla bug report. For starts a loop on modprobe and rmmod fails.

We need udevadm settle (when availble) in between loads, and then the
removal simply needs to be patient. I'll be posting patches to fstests
which demonstrates this quite clearly.

I believe that... this is the way.

  Luis



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux