Mark Salyzyn
a73914c35b
[SCSI] libsas: fix panic when single phy is disabled on a wide port ...
When a wide port is being utilized to a target, if one disables only one
of the
phys, we get an OS crash:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000238
IP: [<ffffffff814ca9b1>] mutex_lock+0x21/0x50
PGD 4103f5067 PUD 41dba9067 PMD 0
Oops: 0002 [#1 ] SMP
last sysfs file: /sys/bus/pci/slots/5/address
CPU 0
Modules linked in: pm8001(U) ses enclosure fuse nfsd exportfs autofs4
ipmi_devintf ipmi_si ipmi_msghandler nfs lockd fscache nfs_acl
auth_rpcgss 8021q fcoe libfcoe garp libfc scsi_transport_fc stp scsi_tgt
llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table ipv6 sr_mod cdrom
dm_mirror dm_region_hash dm_log uinput sg i2c_i801 i2c_core iTCO_wdt
iTCO_vendor_support e1000e mlx4_ib ib_mad ib_core mlx4_en mlx4_core ext3
jbd mbcache sd_mod crc_t10dif usb_storage ata_generic pata_acpi ata_piix
libsas(U) scsi_transport_sas dm_mod [last unloaded: pm8001]
Modules linked in: pm8001(U) ses enclosure fuse nfsd exportfs autofs4
ipmi_devintf ipmi_si ipmi_msghandler nfs lockd fscache nfs_acl
auth_rpcgss 8021q fcoe libfcoe garp libfc scsi_transport_fc stp scsi_tgt
llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table ipv6 sr_mod cdrom
dm_mirror dm_region_hash dm_log uinput sg i2c_i801 i2c_core iTCO_wdt
iTCO_vendor_support e1000e mlx4_ib ib_mad ib_core mlx4_en mlx4_core ext3
jbd mbcache sd_mod crc_t10dif usb_storage ata_generic pata_acpi ata_piix
libsas(U) scsi_transport_sas dm_mod [last unloaded: pm8001]
Pid: 5146, comm: scsi_wq_5 Not tainted
2.6.32-71.29.1.el6.lustre.7.x86_64 #1 Storage Server
RIP: 0010:[<ffffffff814ca9b1>] [<ffffffff814ca9b1>]
mutex_lock+0x21/0x50
RSP: 0018:ffff8803e4e33d30 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000238 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff8803e664c800 RDI: 0000000000000238
RBP: ffff8803e4e33d40 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
R13: 0000000000000238 R14: ffff88041acb7200 R15: ffff88041c51ada0
FS: 0000000000000000(0000) GS:ffff880028200000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000238 CR3: 0000000410143000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process scsi_wq_5 (pid: 5146, threadinfo ffff8803e4e32000, task
ffff8803e4e294a0)
Stack:
ffff8803e664c800 0000000000000000 ffff8803e4e33d70 ffffffffa001f06e
<0> ffff8803e4e33d60 ffff88041c51ada0 ffff88041acb7200 ffff88041bc0aa00
<0> ffff8803e4e33d90 ffffffffa0032b6c 0000000000000014 ffff88041acb7200
Call Trace:
[<ffffffffa001f06e>] sas_port_delete_phy+0x2e/0xa0 [scsi_transport_sas]
[<ffffffffa0032b6c>] sas_unregister_devs_sas_addr+0xac/0xe0 [libsas]
[<ffffffffa0034914>] sas_ex_revalidate_domain+0x204/0x330 [libsas]
[<ffffffffa00307f0>] ? sas_revalidate_domain+0x0/0x90 [libsas]
[<ffffffffa0030855>] sas_revalidate_domain+0x65/0x90 [libsas]
[<ffffffff8108c7d0>] worker_thread+0x170/0x2a0
[<ffffffff81091ea0>] ? autoremove_wake_function+0x0/0x40
[<ffffffff8108c660>] ? worker_thread+0x0/0x2a0
[<ffffffff81091b36>] kthread+0x96/0xa0
[<ffffffff810141ca>] child_rip+0xa/0x20
[<ffffffff81091aa0>] ? kthread+0x0/0xa0
[<ffffffff810141c0>] ? child_rip+0x0/0x20
Code: ff ff 85 c0 75 ed eb d6 66 90 55 48 89 e5 48 83 ec 10 48 89 1c 24
4c 89 64 24 08 0f 1f 44 00 00 48 89 fb e8 92 f4 ff ff 48 89 df <f0> ff
0f 79 05 e8 25 00 00 00 65 48 8b 04 25 08 cc 00 00 48 2d
RIP [<ffffffff814ca9b1>] mutex_lock+0x21/0x50
RSP <ffff8803e4e33d30>
CR2: 0000000000000238
The following patch is admittedly a band-aid, and does not solve the
root cause, but it still is a good candidate for hardening as a pointer
check before reference.
Signed-off-by: Mark Salyzyn <mark_salyzyn@us.xyratex.com>
Tested-by: Jack Wang <jack_wang@usish.com>
Cc: stable@kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2011-10-02 13:28:55 -05:00
2011-09-12 20:00:00 -04:00
2011-08-18 23:58:11 -04:00
2011-09-26 19:40:23 +02:00
2011-08-22 14:21:41 -04:00
2011-09-21 10:22:11 +02:00
2011-09-17 17:16:03 -03:00
2011-08-02 12:43:50 +02:00
2011-09-23 09:46:41 +10:00
2011-08-08 16:33:54 +09:00
2011-07-28 18:26:32 -07:00
2011-09-14 18:09:38 -07:00
2011-08-03 19:06:37 -04:00
2011-07-28 01:30:07 -07:00
2011-09-05 17:08:26 +05:30
2011-08-18 14:07:15 -07:00
2011-08-04 06:32:51 -10:00
2011-09-16 22:22:10 +02:00
2011-08-08 13:53:49 -07:00
2011-09-14 18:09:38 -07:00
2011-09-29 19:23:30 -07:00
2011-09-16 14:09:19 -07:00
2011-09-23 10:39:11 -07:00
2011-09-07 00:13:40 +01:00
2011-08-04 01:30:34 -07:00
2011-09-26 09:28:01 -05:00
2011-09-16 14:09:19 -07:00
2011-09-13 23:44:53 +02:00
2011-07-28 05:58:19 -07:00
2011-09-14 18:09:38 -07:00
2011-09-10 17:21:28 +10:00
2011-09-21 22:18:26 -03:00
2011-07-30 08:36:02 -10:00
2011-09-06 16:37:59 +02:00
2011-09-14 18:09:38 -07:00
2011-09-21 13:20:21 -07:00
2011-08-19 19:02:27 +03:00
2011-09-28 08:39:05 -07:00
2011-08-04 11:26:24 +01:00
2011-09-13 16:08:31 -07:00
2011-07-31 06:23:08 -10:00
2011-08-05 15:21:52 -04:00
2011-08-19 21:01:46 +04:00
2011-08-25 16:25:34 -07:00
2011-08-01 14:05:46 -10:00
2011-09-14 18:09:38 -07:00
2011-09-26 16:40:50 +02:00
2011-10-02 13:28:55 -05:00
2011-08-08 16:33:54 +09:00
2011-09-23 17:28:29 -06:00
2011-09-20 14:17:13 -07:00
2011-09-16 23:47:07 +00:00
2011-08-02 14:51:57 -04:00
2011-09-14 18:09:38 -07:00
2011-09-19 17:15:47 -07:00
2011-09-10 14:00:02 -07:00
2011-08-25 16:25:33 -07:00
2011-09-20 14:32:00 +02:00
2011-09-15 04:32:02 -04:00
2011-09-22 12:59:35 -07:00
a73914c35b