oops in sd_probe_async

[郭高峰]

1) my kernel is 2.6.32-71.el6 (centos)
2) the stack of panic:
Call Trace:
[<ffffffff811de547>] sysfs_add_file_mode+0x57/0xb0
[<ffffffff811de5b1>] sysfs_add_file+0x11/0x20
[<ffffffff811de5e6>] sysfs_create_file+0x26/0x30
[<ffffffff81238713>] elv_register_queue+0x63/0x90
[<ffffffff812428d3>] blk_register_queue+0xb3/0x100
[<ffffffff812484a4>] add_disk+0x94/0x160
[<ffffffffa01a332b>] sd_probe_async+0x13b/0x210 [sd_mod]
[<ffffffff81091d86>] ? add_wait_queue+0x46/0x60
[<ffffffff81098dc2>] async_thread+0x102/0x250
[<ffffffff8105c230>] ? default_wake_function+0x0/0x20
[<ffffffff81098cc0>] ? async_thread+0x0/0x250
[<ffffffff810916c6>] kthread+0x96/0xa0
[<ffffffff810141ca>] child_rip+0xa/0x20
[<ffffffff81091630>] ? kthread+0x0/0xa0
[<ffffffff810141c0>] ? child_rip+0x0/0x20
Code: fb 49 89 f4 48 c7 47 08 00 00 00 00 48 c7 47 10 00 00 00 00 48 c7 47 18 00 00 00 00 48 c7 c7 e0 92 77 81 48 89 33 e8 03 98 2e 00 <49> 8b 74 24 38 48 8b 3d 7f 81 a1 00 4c 89 e1 48 c7 c2 10 ee 1d RIP [<ffffffff811df15d>] sysfs_addrm_start+0x3d/0xd0

3)
4) I think this panic is caused by parallel of sd_probe and sd_remove in sd_mod
5) in the sd_remove of kernel 2.6.36, there is "scsi_autopm_get_device".
Do this function can solve the panic?