From: Neil Horman Date: Fri, 3 May 2013 19:34:15 +0000 (+0000) Subject: libfc: extend ex_lock to protect all of fc_seq_send X-Git-Tag: v3.10~2^2~1^2~1 X-Git-Url: http://git.openpandora.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=fb00cc2353ca22b3278f72d73e65a33486d1dbc7;p=pandora-kernel.git libfc: extend ex_lock to protect all of fc_seq_send This warning was reported recently: WARNING: at drivers/scsi/libfc/fc_exch.c:478 fc_seq_send+0x14f/0x160 [libfc]() (Not tainted) Hardware name: ProLiant DL120 G7 Modules linked in: tcm_fc target_core_iblock target_core_file target_core_pscsi target_core_mod configfs dm_round_robin dm_multipath 8021q garp stp llc bnx2fc cnic uio fcoe libfcoe libfc scsi_transport_fc scsi_tgt autofs4 sunrpc pcc_cpufreq ipv6 hpilo hpwdt e1000e microcode iTCO_wdt iTCO_vendor_support serio_raw shpchp ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif pata_acpi ata_generic ata_piix hpsa dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan] Pid: 5464, comm: target_completi Not tainted 2.6.32-272.el6.x86_64 #1 Call Trace: [] ? warn_slowpath_common+0x87/0xc0 [] ? warn_slowpath_null+0x1a/0x20 [] ? fc_seq_send+0x14f/0x160 [libfc] [] ? ft_queue_status+0x16e/0x210 [tcm_fc] [] ? target_complete_ok_work+0x0/0x4b0 [target_core_mod] [] ? target_complete_ok_work+0x106/0x4b0 [target_core_mod] [] ? target_complete_ok_work+0x0/0x4b0 [target_core_mod] [] ? worker_thread+0x170/0x2a0 [] ? autoremove_wake_function+0x0/0x40 [] ? worker_thread+0x0/0x2a0 [] ? kthread+0x96/0xa0 [] ? child_rip+0xa/0x20 [] ? kthread+0x0/0xa0 [] ? child_rip+0x0/0x20 It occurs because fc_seq_send can have multiple contexts executing within it at the same time, and fc_seq_send doesn't consistently use the ep->ex_lock that protects this structure. Because of that, its possible for one context to clear the INIT bit in the ep->esb_state field while another checks it, leading to the above stack trace generated by the WARN_ON in the function. We should probably undertake the effort to convert access to the fc_exch structures to use rcu, but that a larger work item. To just fix this specific issue, we can just extend the ex_lock protection through the entire fc_seq_send path Signed-off-by: Neil Horman Reported-by: Gris Ge CC: Robert Love Signed-off-by: Robert Love --- Reading git-diff-tree failed