Hot-unplug or delete scsi device causes RHEL 4.6 kernel panic in sysfs_hash_and_remove

Issue

• When a scsi device is hot-unplugged (or deleted via the /sys/block/sdX/device/delete interface), the Red Hat Enterprise Linux 4.6 kernel sometimes panics in sysfs_hash_and_remove(), with the following stack backtrace :

  Unable to handle kernel NULL pointer dereference at 0000000000000010
  RIP:
  <ffffffff801b5203>{sysfs_hash_and_remove+14}
  PML4 4244c067 PGD 11cf12067 PMD 0
  Oops: 0000 [1] SMP
  CPU 3
  Modules linked in: mptctl mptbase ipmi_si(U) ipmi_devintf(U)
  ipmi_msghandler(U) hp_ilo(U) pidentd(U) autofs4 i2c_dev i2c_core
  sunrpc 8021q ide_dump cciss_dump scsi_dump diskdump zlib_deflate
  deadman(U) joydev dm_mirror button battery ac hw_random e1000
  (U) bnx2(U) bond1(U) bonding(U) sg st ext3 jbd dm_mod qla2400(U)
  qla2300(U) qla2xxx(U) cciss(U) qla2xxx_conf(U) usb_storage uh
  ci_hcd ohci_hcd ehci_hcd sd_mod scsi_mod
  Pid: 20295, comm: CtrlLvmFs.sh Not tainted 2.6.9-67.ELsmp
  RIP: 0010:[<ffffffff801b5203>]
  <ffffffff801b5203>{sysfs_hash_and_remove+14}
  RSP: 0018:000001009eda5e28  EFLAGS: 00010246
  RAX: 0000000000000000 RBX: 000001007efdb448 RCX: 0000000000000246
  RDX: ffffffffa0024670 RSI: ffffffff8032cb3b RDI: 0000000000000000
  RBP: 000001007efdb438 R08: ffffffffa0009fc3 R09: 0000000000000246
  R10: 000000000064b090 R11: 0000000000000246 R12: ffffffffa00245e0
  R13: 0000000000000000 R14: ffffffff8032cb3b R15: 000001009eda5f50
  FS:  0000002a9557fb00(0000) GS:ffffffff804f2f00(0000)
  knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 0000000000000010 CR3: 0000000005d44000 CR4: 00000000000006e0
  Process CtrlLvmFs.sh (pid: 20295, threadinfo 000001009eda4000, task
  000001011dd43030)
  Stack: 000001007efdb448 000001007efdb438 ffffffffa00245e0
  0000010117811380
  0000000000650ce0 ffffffff8024e2ba 000001012a768000
  000001007efdb438
  000001007efdb100 000001012a768000
  Call Trace:<ffffffff8024e2ba>{class_device_del+156}
  <ffffffff8024e33e>{class_device_unregister+9}
  <ffffffffa0009f3e>{:scsi_mod:scsi_remove_device+78}
  <ffffffffa0009fd3>{:scsi_mod:sdev_store_delete+16}
  <ffffffff8024c6a7>{dev_attr_store+29}
  <ffffffff801b554f>{sysfs_write_file+194}
  <ffffffff8017af0e>{vfs_write+207}
  <ffffffff8017aff6>{sys_write+69}
  <ffffffff8011026a>{system_call+126}
  

This is not always reproducible - a race condition exists that does not always trigger the panic.