From: Brian King <brking@us.ibm.com>
To: linux-scsi@vger.kernel.org
Subject: scsi_add_device/scsi_remove_device oops
Date: Thu, 01 Jul 2004 18:29:52 -0500 [thread overview]
Message-ID: <40E49E70.9020504@us.ibm.com> (raw)
I am experiencing an oops when calling both scsi_add_device and
scsi_remove_device at the same time. Is the API supposed to be able to
handle this? I can patch around the exact oops I encountered, but it
looks like there would be more problems in this code path as well.
If I am not following the API, I can try putting some more intelligence
in ipr so that I don't try to delete a device that hasn't fully been
added, but I want to make sure I am fixing this the proper way.
Looking at the backtraces, it looks like slave_configure has already
been called on the device and we are constructing the classdev and
trying to destroy it at the same time.
Here are the backtraces:
0xc00000033fecb5c0 0xc000000000043098 .do_page_fault +0x43c
0xc00000033fecb6f0 0xc00000000000ad28 DataAccessSLB_common +0x114
--- Exception: 380: at .sysfs_hash_and_remove +0x2c
0xc00000033fecb9e0 0xc00000000011bc4c .sysfs_hash_and_remove +0x2c
0xc00000033fecb9e0 0xc00000000011d644 (lr) .sysfs_remove_link +0x14
0xc00000033fecba70 0xc00000000011d644 .sysfs_remove_link +0x14
0xc00000033fecbaf0 0xc00000000024d978 .class_device_del +0x1ec
0xc00000033fecbba0 0xc00000000024d9d4 .class_device_unregister +0x1c
0xc00000033fecbc30 0xd000000000095818 .scsi_remove_device +0x54
0xc00000033fecbcb0 0xd0000000000e422c .ipr_worker_thread +0x960
0xc00000033fecbdb0 0xc0000000000746ec .worker_thread +0x24c
0xc00000033fecbed0 0xc00000000007a584 .kthread +0x17c
0xc00000033fecbf90 0xc000000000017924 .kernel_thread +0x4c
and
0xc0000000028e7330 0xc00000000005841c .schedule +0xbc
0xc0000000028e7450 0xc00000000005985c .wait_for_completion +0xec
0xc0000000028e7550 0xd000000000092738 .scsi_wait_req +0x88
0xc0000000028e7600 0xd0000000000574b0 .sd_revalidate_disk +0x160
0xc0000000028e7750 0xd000000000058b6c .sd_probe +0x238
0xc0000000028e7800 0xc00000000024c060 .bus_match +0x94
0xc0000000028e7890 0xc00000000024c130 .device_attach +0x6c
0xc0000000028e7920 0xc00000000024c2c4 .bus_add_device +0x98
0xc0000000028e79b0 0xc00000000024a710 .device_add +0xd0
0xc0000000028e7a50 0xd0000000000959b8 .scsi_sysfs_add_sdev +0x8c
0xc0000000028e7b00 0xd000000000093c54 .scsi_probe_and_add_lun +0x87c
0xc0000000028e7c00 0xd000000000094adc .scsi_add_device +0x78
0xc0000000028e7cb0 0xd0000000000e42c0 .ipr_worker_thread +0x9f4
0xc0000000028e7db0 0xc0000000000746ec .worker_thread +0x24c
0xc0000000028e7ed0 0xc00000000007a584 .kthread +0x17c
0xc0000000028e7f90 0xc000000000017924 .kernel_thread +0x4c
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
next reply other threads:[~2004-07-01 23:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-01 23:29 Brian King [this message]
2004-07-02 20:18 ` [PATCH] scsi_remove_device locking Brian King
2004-07-02 20:23 ` Matthew Wilcox
2004-07-02 20:34 ` Brian King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40E49E70.9020504@us.ibm.com \
--to=brking@us.ibm.com \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.