Re: 2.6.16-rc1 crash in scsi_target_reap_work

[Mike Anderson <andmike@us.ibm.com>]

Brian King <brking@us.ibm.com> wrote:
> I would guess that the -EEXIST is coming from:
> 
> create_dir
> sysfs_create_dir
> create_dir
> kobject_add
> device_add
> 
> Looking at the scsi_target reap code, it looks like there is a race condition. The
> target is removed from the hosts list of targets under the host lock, then the host
> lock is released. If another thread tries to add the same target that is being
> tore down at this point (before device_del), the device_add will fail with EEXIST
> since the sysfs directory for the device still exists.
> 
> Any reason we can't protect the target reaping code from this by grabbing the 
> scan_mutex?


Another manifestation is a bug I was recently looking at where a BUG_ON is
triggered in the aic7xxx driver if someone is removing and adding devices
repeatably.

"Feb  8 14:21:52 test klogd: kernel BUG at
drivers/scsi/aic7xxx/aic7xxx_osm.c:535!"

The scan mutex I believe would not help in the case I describe above as
the issue in this instance is the widow between the call of
"list_del_init(&starget->siblings);" and the call to target_destroy.

-andmike
--
Michael Anderson
andmike@us.ibm.com