Brian King <brking@xxxxxxxxxx> 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@xxxxxxxxxx - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
