- May 17, 2010
-
-
Vasu Dev authored
Currently rtnl mutex is grabbed during fcoe create, destroy, enable and disable operations while sysfs s_active read mutex is already held, but simultaneously other networking events could try grabbing write s_active mutex while rtnl is already held and that is causing circular lock warning, its detailed log pasted at end. In this log, the rtnl was held before write s_active during device renaming but there are more such cases as Joe reported another instance with tg3 open at:- http://www.open-fcoe.org/pipermail/devel/2010-February/008263.html This patch fixes this issue by not waiting for rtnl mutex during fcoe ops, that means if rtnl mutex is not immediately available then restart_syscall() to allow others waiting in line to grab s_active along with rtnl mutex to finish their work first under these mutex. Currently rtnl mutex was grabbed twice during fcoe_destroy call flow, second grab was from fcoe_if_destroy called from fcoe_destroy after dropping rtnl mutex before calling fcoe_if_destroy, so instead made fcoe_if_destroy always called with rtnl mutex held to have this mutex grabbed only once in this code path. However left matching rtnl_unlock as-is in its original place as it was dropped there for good reason since very next call causes synchronous fip worker flush and if rtnl mutex is still held before flush then that would cause new circular warning between fip->recv_work and rtnl mutex, I've added detailed comment for this on fcoe_if_destroy calling and rtnl muxtes unlocking. ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.33.1linux-stable-2.6.33 #1 ------------------------------------------------------- fcoemon/18823 is trying to acquire lock: (fcoe_config_mutex){+.+.+.}, at: [<ffffffffa02ba5fc>] fcoe_create+0x27/0x4f7 [fcoe] but task is already holding lock: (s_active){++++.+}, at: [<ffffffff8115ef93>] sysfs_get_active_two+0x31/0x48 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (s_active){++++.+}: [<ffffffff81077bdb>] __lock_acquire+0xb73/0xd2b [<ffffffff81077e60>] lock_acquire+0xcd/0xf1 [<ffffffff8115e5df>] sysfs_deactivate+0x8b/0xe0 [<ffffffff8115edfb>] sysfs_addrm_finish+0x36/0x55 [<ffffffff8115d0cc>] sysfs_hash_and_remove+0x53/0x6a [<ffffffff8115f353>] sysfs_remove_link+0x21/0x23 [<ffffffff812b6c93>] device_rename+0x99/0xcb [<ffffffff8138dbf0>] dev_change_name+0xd5/0x1d2 [<ffffffff8138deee>] dev_ifsioc+0x201/0x2ac [<ffffffff8138e4ba>] dev_ioctl+0x521/0x632 [<ffffffff81379e43>] sock_do_ioctl+0x3d/0x47 [<ffffffff8137a254>] sock_ioctl+0x213/0x222 [<ffffffff81114614>] vfs_ioctl+0x32/0xa6 [<ffffffff81114b94>] do_vfs_ioctl+0x490/0x4d6 [<ffffffff81114c30>] sys_ioctl+0x56/0x79 [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b -> #1 (rtnl_mutex){+.+.+.}: [<ffffffff81077bdb>] __lock_acquire+0xb73/0xd2b [<ffffffff81077e60>] lock_acquire+0xcd/0xf1 [<ffffffff8142f343>] __mutex_lock_common+0x4b/0x383 [<ffffffff8142f73f>] mutex_lock_nested+0x3e/0x43 [<ffffffff813959f9>] rtnl_lock+0x17/0x19 [<ffffffff8138ccae>] register_netdevice_notifier+0x1e/0x19b [<ffffffffa02580c1>] 0xffffffffa02580c1 [<ffffffff81002069>] do_one_initcall+0x5e/0x15e [<ffffffff81084094>] sys_init_module+0xd8/0x23a [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b -> #0 (fcoe_config_mutex){+.+.+.}: [<ffffffff81077a85>] __lock_acquire+0xa1d/0xd2b [<ffffffff81077e60>] lock_acquire+0xcd/0xf1 [<ffffffff8142f343>] __mutex_lock_common+0x4b/0x383 [<ffffffff8142f73f>] mutex_lock_nested+0x3e/0x43 [<ffffffffa02ba5fc>] fcoe_create+0x27/0x4f7 [fcoe] [<ffffffff810635b1>] param_attr_store+0x27/0x35 [<ffffffff81063619>] module_attr_store+0x26/0x2a [<ffffffff8115dae3>] sysfs_write_file+0x108/0x144 [<ffffffff81107bd1>] vfs_write+0xae/0x10b [<ffffffff81107cee>] sys_write+0x4a/0x6e [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b other info that might help us debug this: 3 locks held by fcoemon/18823: #0: (&buffer->mutex){+.+.+.}, at: [<ffffffff8115da17>] sysfs_write_file+0x3c/0x144 #1: (s_active){++++.+}, at: [<ffffffff8115ef86>] sysfs_get_active_two+0x24/0x48 #2: (s_active){++++.+}, at: [<ffffffff8115ef93>] sysfs_get_active_two+0x31/0x48 stack backtrace: Pid: 18823, comm: fcoemon Tainted: G W 2.6.33.1linux-stable-2.6.33 #1 Call Trace: [<ffffffff81076c38>] print_circular_bug+0xa8/0xb6 [<ffffffff81077a85>] __lock_acquire+0xa1d/0xd2b [<ffffffffa02ba5fc>] ? fcoe_create+0x27/0x4f7 [fcoe] [<ffffffff81077e60>] lock_acquire+0xcd/0xf1 [<ffffffffa02ba5fc>] ? fcoe_create+0x27/0x4f7 [fcoe] [<ffffffffa02ba5fc>] ? fcoe_create+0x27/0x4f7 [fcoe] [<ffffffff8142f343>] __mutex_lock_common+0x4b/0x383 [<ffffffffa02ba5fc>] ? fcoe_create+0x27/0x4f7 [fcoe] [<ffffffff8106ac70>] ? cpu_clock+0x43/0x5e [<ffffffff81074e12>] ? lockstat_clock+0x11/0x13 [<ffffffff81074e40>] ? lock_release_holdtime+0x2c/0x127 [<ffffffff8115ef93>] ? sysfs_get_active_two+0x31/0x48 [<ffffffff8142f73f>] mutex_lock_nested+0x3e/0x43 [<ffffffffa02ba5fc>] fcoe_create+0x27/0x4f7 [fcoe] [<ffffffff810635b1>] param_attr_store+0x27/0x35 [<ffffffff81063619>] module_attr_store+0x26/0x2a [<ffffffff8115dae3>] sysfs_write_file+0x108/0x144 [<ffffffff81107bd1>] vfs_write+0xae/0x10b [<ffffffff81076596>] ? trace_hardirqs_on_caller+0x125/0x150 [<ffffffff81107cee>] sys_write+0x4a/0x6e [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b Signed-off-by:
Vasu Dev <vasu.dev@intel.com> Signed-off-by:
Robert Love <robert.w.love@intel.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de>
-
Robert Love authored
This patch creates a port_id member in struct fc_lport. This allows libfc to just deal with fc_lport instances instead of calling into the fc_host to get the port_id. This change helps in only using symbols necessary for operation from the libfc structures. libfc still needs to change the fc_host_port_id() if the port_id changes so the presentation layer (scsi_transport_fc) can provide the user with the correct value, but libfc shouldn't rely on the presentation layer for operational values. Signed-off-by:
-
Robert Love authored
It doesn't make sense to update the link speed in the is_link_ok() routine. Move it to it's own routine and acquire the device speed when we're configuring the device initially as well as if there are any netdev events received. Signed-off-by:
-
Robert Love authored
The fcf pointer is checked again after this verification making the first check redundant. Remote the first check. Signed-off-by:
-
Robert Love authored
Remove this unused routine. Signed-off-by:
-
Vasu Dev authored
fcoe_create exits using out_nodev label when module is not yet LIVE but this exit path unlocks the rtnl_lock though rtnl lock was not held in this case. So this patch replaces out_nodev with out_nomod to exit w/o unlocking rtnl_lock. Signed-off-by:
-
Joe Eykholt authored
After the recent patch "fixes unnecessary seq id jump" the SCST module fcst stopped working because multi-sequence write data wasn't finding the sequence after the first frame. Add back the setting of the seq_id when the first frame arrives. Also fix indentation on two lines. Signed-off-by:
Joe Eykholt <jeykholt@cisco.com> Signed-off-by:
-
Giridhar Malavali authored
1) Allow transition to NEED RESET state only from READY state for ISP82xx. 2) Avoid infinite ISP aborts when chip reset fails. 3) Code cleanup to remove some of the unused debug code. Signed-off-by:
Lalit Chandivade <lalit.chandivade@qlogic.com> Signed-off-by:
Santosh Vernekar <santosh.vernekar@qlogic.com> Signed-off-by:
Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by:
-
Giridhar Malavali authored
Signed-off-by:
-
Lalit Chandivade authored
The problem occurring is a hw-race where there's an outstanding read-flash operation occurring while the chip is being reset (done via an sg_reset script). After the chip is paused, the read-flash operation never completes and the DPC thread, while trying to complete the reset, is never able to recover, as the HW appears to be hung... The fix is to wait for outstanding flash operation prior to doing a sg_reset -h. And to wait for reset to complete before any flash operations. Note, during the wait, if any of the operation (reset/flash) does not complete, failure is returned to the upper layer. The upper layer either need to fail or retry. Signed-off-by:
-
Mike Waychison authored
The qla2xxx driver uses a port_id_t to mark the start of its enumerations. gcc is complaining that wrap.b24 may be used uninitialized, but this doesn't look to be possible. Silence it. Signed-off-by:
-
Arun Easi authored
Signed-off-by:
Duane Grigsby <duane.grigsby@qlogic.com> Signed-off-by:
-
Madhuranath Iyengar authored
Currently we can only issue the task management (TM) commands via the mailbox mechanism. This is a limitation, since only one mailbox command can be issued at a time. The purpose of this effort is to provide support for issuing and processing the respose to TM and Marker IOCBs asynchronously. Towards achieving this, the consolidated srb architecture that is currently used for BSG and IOCB/Logio commands has been enhanced and used. Signed-off-by:
-
Madhuranath Iyengar authored
Currently, BSG and IOCB/Logio commands have a different framework (srb structs). The purpose of this effort is to consolidate them into a generalized framework for these as well as other asynchronous operations in the future. Signed-off-by:
-
Andrew Vasquez authored
Migrate to a consistent set of debug entries during status-IOCB handling: * group CS_TIMEOUT handling with CS_PORT_UNAVAILABLE and the like (more regrouping of common behaviour). * drop CS_DATA_OVERRUN handling as it now falls into the 'default' case (still returns DID_ERROR). * consolidate CS_RESET and CS_ABORTED handling, as we the only functional difference was a printk() (still returns DID_RESET). * dropped all the earlier inconsistent [qla_]printk()s sprinkled throught the needlessly large case-statement. Failure case I/Os are now logged with a 'standard' format: <command failure details> <command generic details> so, for example a dropped-frame is logged as: qla2xxx 0000:13:00.0: scsi(16:0:0) Dropped frame(s) detected (4000 of 4000 bytes). qla2xxx 0000:13:00.0: scsi(16:0:0) FCP command status: 0x15-0x18 (70018) \ oxid=78 ser=76 cdb=280000 len=4000 rsp_info=0 resid=0 fw_resid=4000 which should now convey all relevant information. Signed-off-by: -
Andrew Vasquez authored
Signed-off-by:
-
Andrew Vasquez authored
Prepare CTX infrastructure for additional asynchronous executions, add generic done() operator, pull CMD definitions. Signed-off-by:
Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by:
-
Harish Zunjarrao authored
The driver should not be unloaded if any application is using it. To disallow driver unload, driver use count must be incremented. Application uses this char device as handle and increases driver use count to avoid possible driver unload. Signed-off-by:
-
Lalit Chandivade authored
Currently error status is cleared only after the uncorrectable fatal errors in the qla2xxx_pci_slot_reset. This fix is added to clear the error status in qla2xxx_pci_resume. This way for both fatal and non-fatal errors the error status gets cleared properly. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=572258 Signed-off-by:
-
Andrew Vasquez authored
With qla2xxx using mid-layer async-scsi-scanning, the link state for disconnected port is displayed wrong. Additional check for cable presence is considered to display proper link state. Signed-off-by:
-
Andrew Vasquez authored
Signed-off-by:
-
- May 03, 2010
-
-
Geert Uytterhoeven authored
Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
-
Geert Uytterhoeven authored
wd33c93_release() has been empty since ages, and sgiwd93.c no longer calls it since its conversion to a proper platform driver 2 years ago. Also remove the callers in the m68k wd33c93 shims. Signed-off-by:
-
Christof Schmitt authored
With debug kernels, the memory allocated with kmem_cache_alloc might be initialized with the poison values 6b and a5. Use kmem_cache_zalloc instead of kmem_cache_alloc to get zeroed memory and not send invalid requests. Signed-off-by:
Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by:
-
Christof Schmitt authored
The FCP channel provides the number of status read buffers to issue. Use the provided number instead of the hardcoded number in zfcp. Reviewed-by:
Swen Schillig <swen@vnet.ibm.com> Signed-off-by:
-
Christof Schmitt authored
Waiting for a free sbal is a operation on the qdio queue. Move the code implementing the wait to zfcp_qdio.c and rename the functions accordingly. Reviewed-by:
-
Christof Schmitt authored
Move the code accessing the qdio sbales and zfcp_qdio_req struct to the zfcp_qdio files and provide helper functions for accessing the qdio related parts. Reviewed-by:
-
Christof Schmitt authored
Instead of dealing with large segments in the scatter-gather lists in zfcp_qdio.c, report the limits to the upper layers. With these limits in place, the code for mapping large data blocks to multiple sbales can be removed. Reviewed-by:
-
Ravi Anand authored
Signed-off-by:
Ravi Anand <ravi.anand@qlogic.com> Signed-off-by:
-
Vikas Chaudhary authored
Signed-off-by:
Vikas Chaudhary <vikas.chaudhary@qlogic.com> Signed-off-by:
Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
-
Vikas Chaudhary authored
* Handles SCSI command aborts. * Serialization srb between error handler and command completion path. Signed-off-by:
-
Vikas Chaudhary authored
used cmd->host_scribble to store iocb command handle. Signed-off-by:
-
