Skip to contentSkip to conversation

BUG_ON in scsi_target_destroy()

-next Sergey Senozhatsky 6 participants 9 messages Apr 11, 2016 – Apr 15, 2016

Subsystems (2)
SCSI Linux-next tree
lore
Share & tools
lore

Sergey Senozhatsky

author
#0 lore raw

Hello,

commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96

Author: Johannes Thumshirn <[email protected]>
Date:   Tue Apr 5 11:50:44 2016 +0200

scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

BUG_ON()s (next-20160411) each time I remove a usb flash

[   49.561600]  [<ffffffffa0087f42>] scsi_target_destroy+0x5a/0xcb [scsi_mod]
[   49.561607]  [<ffffffffa0089099>] scsi_target_reap+0x4a/0x4f [scsi_mod]
[   49.561613]  [<ffffffffa008b453>] __scsi_remove_device+0xc3/0xd0 [scsi_mod]
[   49.561619]  [<ffffffffa0089d7b>] scsi_forget_host+0x52/0x63 [scsi_mod]
[   49.561623]  [<ffffffffa0080dbc>] scsi_remove_host+0x8c/0x102 [scsi_mod]
[   49.561627]  [<ffffffffa015c447>] usb_stor_disconnect+0x6b/0xab [usb_storage]
[   49.561634]  [<ffffffffa0013f73>] usb_unbind_interface+0x77/0x1ca [usbcore]
[   49.561636]  [<ffffffff813ae064>] __device_release_driver+0x9d/0x121
[   49.561638]  [<ffffffff813ae10b>] device_release_driver+0x23/0x30
[   49.561639]  [<ffffffff813ad2d1>] bus_remove_device+0xfb/0x10e
[   49.561641]  [<ffffffff813aac05>] device_del+0x164/0x1e6
[   49.561648]  [<ffffffffa0011b09>] ? remove_intf_ep_devs+0x3b/0x48 [usbcore]
[   49.561655]  [<ffffffffa001200e>] usb_disable_device+0x84/0x1a5 [usbcore]
[   49.561661]  [<ffffffffa000ac7b>] usb_disconnect+0x94/0x19f [usbcore]
[   49.561667]  [<ffffffffa000c2ab>] hub_event+0x5c1/0xdea [usbcore]
[   49.561670]  [<ffffffff810530b1>] process_one_work+0x1dc/0x37f
[   49.561672]  [<ffffffff81053dc5>] worker_thread+0x282/0x36d
[   49.561673]  [<ffffffff81053b43>] ? rescuer_thread+0x2ae/0x2ae
[   49.561675]  [<ffffffff810580a8>] kthread+0xd2/0xda
[   49.561678]  [<ffffffff814bbf92>] ret_from_fork+0x22/0x40
[   49.561679]  [<ffffffff81057fd6>] ? kthread_worker_fn+0x13e/0x13e
	-ss
#1 lore raw

Hi Sergey, Xiong,

Can you try below patch?

Quoted 33 lines · On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote:

Hello,

commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96

Author: Johannes Thumshirn <[email protected]>
Date:   Tue Apr 5 11:50:44 2016 +0200

scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

BUG_ON()s (next-20160411) each time I remove a usb flash

[   49.561600]  [<ffffffffa0087f42>] scsi_target_destroy+0x5a/0xcb [scsi_mod]
[   49.561607]  [<ffffffffa0089099>] scsi_target_reap+0x4a/0x4f [scsi_mod]
[   49.561613]  [<ffffffffa008b453>] __scsi_remove_device+0xc3/0xd0 [scsi_mod]
[   49.561619]  [<ffffffffa0089d7b>] scsi_forget_host+0x52/0x63 [scsi_mod]
[   49.561623]  [<ffffffffa0080dbc>] scsi_remove_host+0x8c/0x102 [scsi_mod]
[   49.561627]  [<ffffffffa015c447>] usb_stor_disconnect+0x6b/0xab [usb_storage]
[   49.561634]  [<ffffffffa0013f73>] usb_unbind_interface+0x77/0x1ca [usbcore]
[   49.561636]  [<ffffffff813ae064>] __device_release_driver+0x9d/0x121
[   49.561638]  [<ffffffff813ae10b>] device_release_driver+0x23/0x30
[   49.561639]  [<ffffffff813ad2d1>] bus_remove_device+0xfb/0x10e
[   49.561641]  [<ffffffff813aac05>] device_del+0x164/0x1e6
[   49.561648]  [<ffffffffa0011b09>] ? remove_intf_ep_devs+0x3b/0x48 [usbcore]
[   49.561655]  [<ffffffffa001200e>] usb_disable_device+0x84/0x1a5 [usbcore]
[   49.561661]  [<ffffffffa000ac7b>] usb_disconnect+0x94/0x19f [usbcore]
[   49.561667]  [<ffffffffa000c2ab>] hub_event+0x5c1/0xdea [usbcore]
[   49.561670]  [<ffffffff810530b1>] process_one_work+0x1dc/0x37f
[   49.561672]  [<ffffffff81053dc5>] worker_thread+0x282/0x36d
[   49.561673]  [<ffffffff81053b43>] ? rescuer_thread+0x2ae/0x2ae
[   49.561675]  [<ffffffff810580a8>] kthread+0xd2/0xda
[   49.561678]  [<ffffffff814bbf92>] ret_from_fork+0x22/0x40
[   49.561679]  [<ffffffff81057fd6>] ? kthread_worker_fn+0x13e/0x13e
Quoted 6 lines
	-ss

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

drivers/scsi/scsi_sysfs.c +4 -1
index 0734927..0c00928 100644
@@ -1276,6 +1276,7 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
 void __scsi_remove_device(struct scsi_device *sdev)
 {
 	struct device *dev = &sdev->sdev_gendev;
+	struct scsi_target *starget;
 
 	/*
 	 * This cleanup path is not reentrant and while it is impossible

@@ -1315,7 +1316,9 @@ void __scsi_remove_device(struct scsi_device *sdev)
 	 * remoed sysfs visibility from the device, so make the target
 	 * invisible if this was the last device underneath it.
 	 */
-	scsi_target_reap(scsi_target(sdev));
+	starget = scsi_target(sdev);
+	starget->state = STARGET_REMOVE;
+	scsi_target_reap(starget);
 
 	put_device(dev);
 }
Signature · 11 lines
Johannes Thumshirn                                                                                Storage
[email protected]                                                             +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#2 lore raw

Hi,

Quoted 3 lines · Johannes Thumshirn

Hi Sergey, Xiong,

Can you try below patch?

it panics my system.
first it warn_on-s in lib/kobject.c:244

then NULL dereferences
do_scan_async
__scsi_remove_device
scsi_target_reap
device_del

    dpm_sysfs_remove
     sysfs_unmerge_group
      kernfs_find_and_get_ns
       kernfs_find_ns

	-ss
#3 lore raw
Quoted 15 lines · On Mittwoch, 13. April 2016 23:47:04 CEST Sergey Senozhatsky wrote:

Hi,

Quoted 3 lines · Johannes Thumshirn

Hi Sergey, Xiong,

Can you try below patch?

it panics my system.
first it warn_on-s in lib/kobject.c:244

then NULL dereferences
do_scan_async
__scsi_remove_device
scsi_target_reap
device_del

Quoted 7 lines
    dpm_sysfs_remove
     sysfs_unmerge_group
      kernfs_find_and_get_ns
       kernfs_find_ns

	-ss

Thanks for the update, I'll have a look into the callchain

Signature · 6 lines
Johannes Thumshirn                                                                                Storage
[email protected]                                                             +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
#4 lore raw
In reply to Johannes Thumshirn
Quoted 79 lines · Johannes Thumshirn

Hi Sergey, Xiong,

Can you try below patch?

Quoted 55 lines · On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote:

Hello,

commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96

Author: Johannes Thumshirn <[email protected]>
Date:   Tue Apr 5 11:50:44 2016 +0200

scsi: Add intermediate STARGET_REMOVE state to
scsi_target_state

BUG_ON()s (next-20160411) each time I remove a usb flash

[   49.561600]  [<ffffffffa0087f42>] scsi_target_destroy+0x5a/0xcb
[scsi_mod]
[   49.561607]  [<ffffffffa0089099>] scsi_target_reap+0x4a/0x4f
[scsi_mod]
[   49.561613]  [<ffffffffa008b453>] __scsi_remove_device+0xc3/0xd0
[scsi_mod]
[   49.561619]  [<ffffffffa0089d7b>] scsi_forget_host+0x52/0x63
[scsi_mod]
[   49.561623]  [<ffffffffa0080dbc>] scsi_remove_host+0x8c/0x102
[scsi_mod]
[   49.561627]  [<ffffffffa015c447>] usb_stor_disconnect+0x6b/0xab
[usb_storage]
[   49.561634]  [<ffffffffa0013f73>]
usb_unbind_interface+0x77/0x1ca [usbcore]
[   49.561636]  [<ffffffff813ae064>]
__device_release_driver+0x9d/0x121
[   49.561638]  [<ffffffff813ae10b>]
device_release_driver+0x23/0x30
[   49.561639]  [<ffffffff813ad2d1>] bus_remove_device+0xfb/0x10e
[   49.561641]  [<ffffffff813aac05>] device_del+0x164/0x1e6
[   49.561648]  [<ffffffffa0011b09>] ?
remove_intf_ep_devs+0x3b/0x48 [usbcore]
[   49.561655]  [<ffffffffa001200e>] usb_disable_device+0x84/0x1a5
[usbcore]
[   49.561661]  [<ffffffffa000ac7b>] usb_disconnect+0x94/0x19f
[usbcore]
[   49.561667]  [<ffffffffa000c2ab>] hub_event+0x5c1/0xdea
[usbcore]
[   49.561670]  [<ffffffff810530b1>] process_one_work+0x1dc/0x37f
[   49.561672]  [<ffffffff81053dc5>] worker_thread+0x282/0x36d
[   49.561673]  [<ffffffff81053b43>] ? rescuer_thread+0x2ae/0x2ae
[   49.561675]  [<ffffffff810580a8>] kthread+0xd2/0xda
[   49.561678]  [<ffffffff814bbf92>] ret_from_fork+0x22/0x40
[   49.561679]  [<ffffffff81057fd6>] ?

kthread_worker_fn+0x13e/0x13e

	-ss

--
To unsubscribe from this list: send the line "unsubscribe linux -scsi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

drivers/scsi/scsi_sysfs.c +1 -0
index 0734927..0c00928 100644
@@ -1276,6 +1276,7 @@ int scsi_sysfs_add_sdev(struct scsi_device
 *sdev)
 void __scsi_remove_device(struct scsi_device *sdev)
 {
 	struct device *dev = &sdev->sdev_gendev;
+	struct scsi_target *starget;
 
 	/*

* This cleanup path is not reentrant and while it is
impossible

drivers/scsi/scsi_sysfs.c +0 -0
@@ -1315,7 +1316,9 @@ void __scsi_remove_device(struct scsi_device
 *sdev)
 	 * remoed sysfs visibility from the device, so make the

target

drivers/scsi/scsi_sysfs.c

Quoted 6 lines
drivers/scsi/scsi_sysfs.c +3 -1
 	 * invisible if this was the last device underneath it.
 	 */
-	scsi_target_reap(scsi_target(sdev));
+	starget = scsi_target(sdev);
+	starget->state = STARGET_REMOVE;
+	scsi_target_reap(starget);

How about good grief no! A device with multiple targets will get it's lists screwed with this

The STARGET_REMOVE state you added only applies to the case we're trying to kill a target. In the natural operation case, which is what everyone else is running into, we will try to remove a running target when it has no more scsi devices left on it. So the correct patch should be to make the BUG_ON see this:

James

---

drivers/scsi/scsi_scan.c +1 -2
index 27df7e7..e0a78f5 100644
@@ -319,8 +319,7 @@ static void scsi_target_destroy(struct scsi_target *starget)
 	struct Scsi_Host *shost = dev_to_shost(dev->parent);
 	unsigned long flags;
 
-	BUG_ON(starget->state != STARGET_REMOVE &&
-	       starget->state != STARGET_CREATED);
+	BUG_ON(starget->state == STARGET_DEL);
 	starget->state = STARGET_DEL;
 	transport_destroy_device(dev);
 	spin_lock_irqsave(shost->host_lock, flags);
author
#5 lore raw

Hello,

On (04/13/16 08:14), James Bottomley wrote:
[..]

Quoted 8 lines

How about good grief no! A device with multiple targets will get it's lists screwed with this

The STARGET_REMOVE state you added only applies to the case we're trying to kill a target. In the natural operation case, which is what everyone else is running into, we will try to remove a running target when it has no more scsi devices left on it. So the correct patch should be to make the BUG_ON see this:

works for me.

Reported-and-tested-by Sergey Senozhatsky <[email protected]>
	-ss
Quoted 19 lines

James

---

drivers/scsi/scsi_scan.c +1 -2
index 27df7e7..e0a78f5 100644
@@ -319,8 +319,7 @@ static void scsi_target_destroy(struct scsi_target *starget)
 	struct Scsi_Host *shost = dev_to_shost(dev->parent);
 	unsigned long flags;
 
-	BUG_ON(starget->state != STARGET_REMOVE &&
-	       starget->state != STARGET_CREATED);
+	BUG_ON(starget->state == STARGET_DEL);
 	starget->state = STARGET_DEL;
 	transport_destroy_device(dev);
 	spin_lock_irqsave(shost->host_lock, flags);
#6 lore raw
In reply to James Bottomley

Hi,

Quoted 106 lines · James Bottomley
Quoted 81 lines · Johannes Thumshirn

Hi Sergey, Xiong,

Can you try below patch?

Quoted 55 lines · On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote:

Hello,

commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96

Author: Johannes Thumshirn <[email protected]>
Date:   Tue Apr 5 11:50:44 2016 +0200

scsi: Add intermediate STARGET_REMOVE state to
scsi_target_state

BUG_ON()s (next-20160411) each time I remove a usb flash

[   49.561600]  [<ffffffffa0087f42>] scsi_target_destroy+0x5a/0xcb
[scsi_mod]
[   49.561607]  [<ffffffffa0089099>] scsi_target_reap+0x4a/0x4f
[scsi_mod]
[   49.561613]  [<ffffffffa008b453>] __scsi_remove_device+0xc3/0xd0
[scsi_mod]
[   49.561619]  [<ffffffffa0089d7b>] scsi_forget_host+0x52/0x63
[scsi_mod]
[   49.561623]  [<ffffffffa0080dbc>] scsi_remove_host+0x8c/0x102
[scsi_mod]
[   49.561627]  [<ffffffffa015c447>] usb_stor_disconnect+0x6b/0xab
[usb_storage]
[   49.561634]  [<ffffffffa0013f73>]
usb_unbind_interface+0x77/0x1ca [usbcore]
[   49.561636]  [<ffffffff813ae064>]
__device_release_driver+0x9d/0x121
[   49.561638]  [<ffffffff813ae10b>]
device_release_driver+0x23/0x30
[   49.561639]  [<ffffffff813ad2d1>] bus_remove_device+0xfb/0x10e
[   49.561641]  [<ffffffff813aac05>] device_del+0x164/0x1e6
[   49.561648]  [<ffffffffa0011b09>] ?
remove_intf_ep_devs+0x3b/0x48 [usbcore]
[   49.561655]  [<ffffffffa001200e>] usb_disable_device+0x84/0x1a5
[usbcore]
[   49.561661]  [<ffffffffa000ac7b>] usb_disconnect+0x94/0x19f
[usbcore]
[   49.561667]  [<ffffffffa000c2ab>] hub_event+0x5c1/0xdea
[usbcore]
[   49.561670]  [<ffffffff810530b1>] process_one_work+0x1dc/0x37f
[   49.561672]  [<ffffffff81053dc5>] worker_thread+0x282/0x36d
[   49.561673]  [<ffffffff81053b43>] ? rescuer_thread+0x2ae/0x2ae
[   49.561675]  [<ffffffff810580a8>] kthread+0xd2/0xda
[   49.561678]  [<ffffffff814bbf92>] ret_from_fork+0x22/0x40
[   49.561679]  [<ffffffff81057fd6>] ?

kthread_worker_fn+0x13e/0x13e

    -ss

--
To unsubscribe from this list: send the line "unsubscribe linux -scsi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

drivers/scsi/scsi_sysfs.c +1 -0
index 0734927..0c00928 100644
@@ -1276,6 +1276,7 @@ int scsi_sysfs_add_sdev(struct scsi_device
 *sdev)
 void __scsi_remove_device(struct scsi_device *sdev)
 {
      struct device *dev = &sdev->sdev_gendev;
+     struct scsi_target *starget;
 
      /*

* This cleanup path is not reentrant and while it is
impossible

drivers/scsi/scsi_sysfs.c +0 -0
@@ -1315,7 +1316,9 @@ void __scsi_remove_device(struct scsi_device
 *sdev)
       * remoed sysfs visibility from the device, so make the

target
* invisible if this was the last device underneath it. */

drivers/scsi/scsi_sysfs.c

Quoted 4 lines
drivers/scsi/scsi_sysfs.c +3 -1
-     scsi_target_reap(scsi_target(sdev));
+     starget = scsi_target(sdev);
+     starget->state = STARGET_REMOVE;
+     scsi_target_reap(starget);

How about good grief no! A device with multiple targets will get it's lists screwed with this

The STARGET_REMOVE state you added only applies to the case we're trying to kill a target. In the natural operation case, which is what everyone else is running into, we will try to remove a running target when it has no more scsi devices left on it. So the correct patch should be to make the BUG_ON see this:

James

---

drivers/scsi/scsi_scan.c +0 -0
index 27df7e7..e0a78f5 100644

drivers/scsi/scsi_scan.c static void scsi_target_destroy(struct scsi_target *starget) · line 325

Quoted 9 lines
drivers/scsi/scsi_scan.c +1 -2
@@ -319,8 +319,7 @@ static void scsi_target_destroy(struct scsi_target *starget)
        struct Scsi_Host *shost = dev_to_shost(dev->parent);
        unsigned long flags;
 
-       BUG_ON(starget->state != STARGET_REMOVE &&
-              starget->state != STARGET_CREATED);
+       BUG_ON(starget->state == STARGET_DEL);
        starget->state = STARGET_DEL;
        transport_destroy_device(dev);
        spin_lock_irqsave(shost->host_lock, flags);

This will survive modprobe -r scsi_debug ..

Just to make sure, is this _REMOVE state able to do the latter thing what it was trying to do, in this way ?

commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96

Author: Johannes Thumshirn <[email protected]>
Date:   Tue Apr 5 11:50:44 2016 +0200

scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

Add intermediate STARGET_REMOVE state to scsi_target_state to avoid running into the BUG_ON() in scsi_target_reap(). The STARGET_REMOVE state is only valid in the path from scsi_remove_target() to scsi_target_destroy() indicating this target is going to be removed.

This re-fixes the problem introduced in commits bc3f02a795d3 ("[SCSI]
scsi_remove_target: fix softlockup regression on hot remove") and 40998193560d ("scsi: restart list search after unlock in scsi_remove_target") in a more comprehensive way.

#7 lore raw
In reply to James Bottomley
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"James" == James Bottomley <[email protected]> writes:

James> The STARGET_REMOVE state you added only applies to the case we're James> trying to kill a target. In the natural operation case, which is James> what everyone else is running into, we will try to remove a James> running target when it has no more scsi devices left on it. So James> the correct patch should be to make the BUG_ON see this:

Commit amended.

Signature · 1 line
Martin K. Petersen	Oracle Linux Engineering
#8 lore raw
In reply to Johannes Thumshirn

Hi,

Quoted 3 lines · Johannes Thumshirn

Hi Sergey, Xiong,

Can you try below patch?

This survives modprobe -r scsi_debug.

Quoted 55 lines · On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote:
Quoted 39 lines

Hello,

commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96

Author: Johannes Thumshirn <[email protected]>
Date:   Tue Apr 5 11:50:44 2016 +0200

scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

BUG_ON()s (next-20160411) each time I remove a usb flash

[   49.561600]  [<ffffffffa0087f42>] scsi_target_destroy+0x5a/0xcb [scsi_mod]
[   49.561607]  [<ffffffffa0089099>] scsi_target_reap+0x4a/0x4f [scsi_mod]
[   49.561613]  [<ffffffffa008b453>] __scsi_remove_device+0xc3/0xd0 [scsi_mod]
[   49.561619]  [<ffffffffa0089d7b>] scsi_forget_host+0x52/0x63 [scsi_mod]
[   49.561623]  [<ffffffffa0080dbc>] scsi_remove_host+0x8c/0x102 [scsi_mod]
[   49.561627]  [<ffffffffa015c447>] usb_stor_disconnect+0x6b/0xab [usb_storage]
[   49.561634]  [<ffffffffa0013f73>] usb_unbind_interface+0x77/0x1ca [usbcore]
[   49.561636]  [<ffffffff813ae064>] __device_release_driver+0x9d/0x121
[   49.561638]  [<ffffffff813ae10b>] device_release_driver+0x23/0x30
[   49.561639]  [<ffffffff813ad2d1>] bus_remove_device+0xfb/0x10e
[   49.561641]  [<ffffffff813aac05>] device_del+0x164/0x1e6
[   49.561648]  [<ffffffffa0011b09>] ? remove_intf_ep_devs+0x3b/0x48 [usbcore]
[   49.561655]  [<ffffffffa001200e>] usb_disable_device+0x84/0x1a5 [usbcore]
[   49.561661]  [<ffffffffa000ac7b>] usb_disconnect+0x94/0x19f [usbcore]
[   49.561667]  [<ffffffffa000c2ab>] hub_event+0x5c1/0xdea [usbcore]
[   49.561670]  [<ffffffff810530b1>] process_one_work+0x1dc/0x37f
[   49.561672]  [<ffffffff81053dc5>] worker_thread+0x282/0x36d
[   49.561673]  [<ffffffff81053b43>] ? rescuer_thread+0x2ae/0x2ae
[   49.561675]  [<ffffffff810580a8>] kthread+0xd2/0xda
[   49.561678]  [<ffffffff814bbf92>] ret_from_fork+0x22/0x40
[   49.561679]  [<ffffffff81057fd6>] ? kthread_worker_fn+0x13e/0x13e
      -ss

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

drivers/scsi/scsi_sysfs.c +1 -0
index 0734927..0c00928 100644
@@ -1276,6 +1276,7 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
 void __scsi_remove_device(struct scsi_device *sdev)
 {
        struct device *dev = &sdev->sdev_gendev;
+       struct scsi_target *starget;
 
        /*
         * This cleanup path is not reentrant and while it is impossible

drivers/scsi/scsi_sysfs.c void __scsi_remove_device(struct scsi_device *sdev) · line 1321

Quoted 7 lines
drivers/scsi/scsi_sysfs.c +3 -1
@@ -1315,7 +1316,9 @@ void __scsi_remove_device(struct scsi_device *sdev)
         * remoed sysfs visibility from the device, so make the target
         * invisible if this was the last device underneath it.
         */
-       scsi_target_reap(scsi_target(sdev));
+       starget = scsi_target(sdev);
+       starget->state = STARGET_REMOVE;
+       scsi_target_reap(starget);

Yes, scsi_target_reap is alse called from __scsi_remove_device, and ->state is _RUNNING here.

Quoted 7 lines
drivers/scsi/scsi_sysfs.c +0 -1
        put_device(dev);
 }
 
 
 
--
Quoted 7 lines

Johannes Thumshirn Storage
[email protected] +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html