- 18 7月, 2014 31 次提交
-
-
由 Christoph Hellwig 提交于
We should call the device handler prep_fn for all TYPE_FS requests, not just simple read/write calls that are handled by the disk driver. Restructure the common I/O code to call the prep_fn handler and zero out the CDB, and just leave the call to scsi_init_io to the ULDs. Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Reviewed-by: NHannes Reinecke <hare@suse.de>
-
由 Christoph Hellwig 提交于
scsi_init_io should only be called for requests that transfer data, so move the assert that a request has segments from the callers into scsi_init_io. Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Reviewed-by: NHannes Reinecke <hare@suse.de>
-
由 Maurizio Lombardi 提交于
During IO with fabric faults, one generally sees several "Unhandled error code" messages in the syslog as shown below: sd 4:0:6:2: [sdbw] Unhandled error code sd 4:0:6:2: [sdbw] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK sd 4:0:6:2: [sdbw] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sdbw, sector 0 This comes from scsi_io_completion (in scsi_lib.c) while handling error codes other than DID_RESET or not deferred sense keys i.e. this is actually handled by the SCSI mid layer. But what gets displayed here is "Unhandled error code" which is quite misleading as it indicates something that is not addressed by the mid layer. The description string is based on the sense key and sometimes on the additional sense code; since the ACTION_FAIL case always prints the sense key and the additional sense code, this patch removes the description string completely because it does not add useful information. Signed-off-by: NMaurizio Lombardi <mlombard@redhat.com> Reviewed-by: NHannes Reinecke <hare@suse.de> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Douglas Gilbert 提交于
While checking what scsi_adjust_queue_depth() did I thought its switch statement could be clearer: - remove redundant assignment (to sdev->queue_depth) - re-order cases (thus removing the fall-through) Signed-off-by: NDouglas Gilbert <dgilbert@interlog.com> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Reviewed-by: NRobert Elliott <elliott@hp.com> Tested-by: NRobert Elliott <elliott@hp.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Christoph Hellwig 提交于
Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NHannes Reinecke <hare@suse.de>
-
由 Bart Van Assche 提交于
Now that the ibmvstgt driver as the only user of scsi_tgt is gone, the scsi_tgt kernel module, the CONFIG_SCSI_TGT, CONFIG_SCSI_SRP_TGT_ATTRS and CONFIG_SCSI_FC_TGT_ATTRS kbuild variable, the scsi_host_template transfer_response method are no longer needed. [hch: minor updates to the current tree, changelog update] Signed-off-by: NBart Van Assche <bvanassche@acm.org> Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NHannes Reinecke <hare@suse.de>
-
由 Christoph Hellwig 提交于
Remove the libsrp module which was only used by the now removed ibmvstgt driver. Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NHannes Reinecke <hare@suse.de>
-
由 Christoph Hellwig 提交于
The IBM virtual SCSI protocol has been obsoleted by ibmvfc, and there are no reported of the driver left. Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NHannes Reinecke <hare@suse.de>
-
由 Hannes Reinecke 提交于
Using dev_printk variants prefixes the logging message with the originating device, which makes debugging easier. Signed-off-by: NHannes Reinecke <hare@suse.de> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Hannes Reinecke 提交于
Signed-off-by: NHannes Reinecke <hare@suse.de> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Hannes Reinecke 提交于
Update the st driver to use dev_printk() variants instead of plain printk(); this will prefix logging messages with the appropriate device. Signed-off-by: NHannes Reinecke <hare@suse.de> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Hannes Reinecke 提交于
Update the ch driver to use dev_printk() variants instead of plain printk(); this will prefix logging messages with the appropriate device. Signed-off-by: NHannes Reinecke <hare@suse.de> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Hannes Reinecke 提交于
Update the sg driver to use dev_printk() variants instead of plain printk(); this will prefix logging messages with the appropriate device. Signed-off-by: NHannes Reinecke <hare@suse.de> Acked-by: NDoug Gilbert <dgilbert@interlog.com> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Hannes Reinecke 提交于
Update the sr driver to use dev_printk() variants instead of plain printk(); this will prefix logging messages with the appropriate device. Signed-off-by: NHannes Reinecke <hare@suse.de> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Hannes Reinecke 提交于
scsilun_to_int() has an error which prevents it from generating correct LUN numbers for 64bit values. Also we should remove the misleading comment about portions of the LUN being ignored; the initiator should treat the LUN as an opaque value. And, finally, the example given should use the correct prefix (here: extended flat space addressing scheme). This patch includes the modifications suggested by Bart van Assche. Cc: Bart van Assche <bvanassche@acm.org> Cc: Christoph Hellwig <hch@infradead.org> Signed-off-by: NHannes Reinecke <hare@suse.de> Reviewed-by: NJames Bottomley <jbottomley@parallels.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Hannes Reinecke 提交于
Now that we're using 64-bit LUNs internally we need to increase the size of max_luns to 64 bits, too. Signed-off-by: NHannes Reinecke <hare@suse.de> Reviewed-by: NChristoph Hellwig <hch@infradead.org> Reviewed-by: NEwan Milne <emilne@redhat.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Hannes Reinecke 提交于
The SCSI standard defines 64-bit values for LUNs, and large arrays employing large or hierarchical LUN numbers become more and more common. So update the linux SCSI stack to use 64-bit LUN numbers. Signed-off-by: NHannes Reinecke <hare@suse.de> Reviewed-by: NChristoph Hellwig <hch@infradead.org> Reviewed-by: NEwan Milne <emilne@redhat.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Hannes Reinecke 提交于
Older HBAs are only capable of supporting 16-bit LUNs, so we need to make sure to adjust max_lun accordingly. Signed-off-by: NHannes Reinecke <hare@suse.de> Acked-by: NChad Dupuis <chad.dupuis@qlogic.com> Reviewed-by: NEwan Milne <emilne@redhat.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Hannes Reinecke 提交于
Sequential scan for more than 256 LUNs is very fragile as LUNs might not be numbered sequentially after that point. SAM revisions later than SCSI-3 impose a structure on LUNs larger than 256, making LUN numbers between 256 and 16384 illegal. SCSI-3, however allows for plain 64-bit numbers with no internal structure. So restrict sequential LUN scan to 256 LUNs and add a new blacklist flag 'BLIST_SCSI3LUN' to scan up to max_lun devices. Signed-off-by: NHannes Reinecke <hare@suse.de> Reviewed-by: NEwan Milne <emilne@redhat.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Hannes Reinecke 提交于
Obsolete; either use 'max_lun' if the host supports only a limited number of LUNs or BLIST_NOLUN if the target has problems addressing more than one LUN. Signed-off-by: NHannes Reinecke <hare@suse.de> Reviewed-by: NEwan Milne <emilne@redhat.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Douglas Gilbert 提交于
This addresses a problem reported by Vaughan Cao concerning the correctness of the O_EXCL logic in the sg driver. POSIX doesn't defined O_EXCL semantics on devices but "allow only one open file descriptor at a time per sg device" is a rough definition. The sg driver's semantics have been to wait on an open() when O_NONBLOCK is not given and there are O_EXCL headwinds. Nasty things can happen during that wait such as the device being detached (removed). So multiple locks are reworked in this patch making it large and hard to break down into digestible bits. This patch is against Linus's current git repository which doesn't include any sg patches sent in the last few weeks. Hence this patch touches as little as possible that it doesn't need to and strips out most SCSI_LOG_TIMEOUT() changes in v3 because Hannes said he was going to rework all that stuff. The sg3_utils package has several test programs written to test this patch. See examples/sg_tst_excl*.cpp . Not all the locks and flags in sg have been re-worked in this patch, notably sg_request::done . That can wait for a follow-up patch if this one meets with approval. Signed-off-by: NDouglas Gilbert <dgilbert@interlog.com> Reviewed-by: NHannes Reinecke <hare@suse.de>
-
由 Douglas Gilbert 提交于
When the SG_IO ioctl was copied into the block layer and later into the bsg driver, subtle differences emerged. One difference is the way injected commands are queued through the block layer (i.e. this is not SCSI device queueing nor SATA NCQ). Summarizing: - SG_IO in the block layer: blk_exec*(at_head=false) - sg SG_IO: at_head=true - bsg SG_IO: at_head=true Some time ago Boaz Harrosh introduced a sg v4 flag called BSG_FLAG_Q_AT_TAIL to override the bsg driver default. This patch does the equivalent for the sg driver. ChangeLog: Introduce SG_FLAG_Q_AT_TAIL flag to cause commands to be injected into the block layer with at_head=false. Signed-off-by: NDouglas Gilbert <dgilbert@interlog.com> Reviewed-by: NMike Christie <michaelc@cs.wisc.edu> Reviewed-by: NEwan D. Milne <emilne@redhat.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Douglas Gilbert 提交于
- remove the 16 byte CDB (SCSI command) length limit from the sg driver by handling longer CDBs the same way as the bsg driver. Remove comment from sg.h public interface about the cmd_len field being limited to 16 bytes. - remove some dead code caused by this change - cleanup comment block at the top of sg.h, fix urls Signed-off-by: NDouglas Gilbert <dgilbert@interlog.com> Reviewed-by: NMike Christie <michaelc@cs.wisc.edu> Reviewed-by: NHannes Reinecke <hare@suse.de> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Martin K. Petersen 提交于
Until now the per-command transfer length has exclusively been gated by the max_sectors parameter in the scsi_host template. Given that the size of this parameter has been bumped to an unsigned int we have to be careful not to exceed the target device's capabilities. If the if the device specifies a Maximum Transfer Length in the Block Limits VPD we'll use that value. Otherwise we'll use 0xffffffff for devices that have use_16_for_rw set and 0xffff for the rest. We then combine the chosen disk limit with max_sectors in the host template. The smaller of the two will be used to set the max_hw_sectors queue limit. Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Reviewed-by: NEwan D. Milne <emilne@redhat.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Clément Calmels 提交于
In init_sd function, if kmem_cache_create or mempool_create_slab_pools calls fail, the error will not be correclty reported because class_register previously set the value of err to 0. Signed-off-by: NClément Calmels <clement.calmels@free.fr> Reviewed-by: NEwan D. Milne <emilne@redhat.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Vaughan Cao 提交于
This is a fix for commit 39c60a09 "sd: fix array cache flushing bug causing performance problems" We must notify the block layer via q->flush_flags after a temporary change of the cache_type to write through. Without this, a SYNCHRONIZE CACHE command will still be generated. This patch factors out a helper that can be called from sd_revalidate_disk and cache_type_store. Signed-off-by: NVaughan Cao <vaughan.cao@oracle.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Akinobu Mita 提交于
This change enables to test read/write commands with huge transfer length such as 1GB. For example: # modprobe scsi_debug dev_size_mb=1024 clustering=1 opts=1 # cat /sys/block/$DEV/queue/max_hw_sectors_kb > \ /sys/block/$DEV/queue/max_sectors_kb # fio --name=test --rw=write --bs=1g --size=1g --filename=/dev/$DEV \ --mem=mmaphuge --direct=1 The data type of max_sectors in scsi_host_template has been extended to unsigned int by the previous change. So we can increase it from 0xffff to 0xffffffff to allow such huge transfer length. Also, this increases sg_tablesize and max_segment_size, otherwise the maximum transfer length is limited to 64MB. (sg_tablesize * max_segment_size = 256 * 256KB) Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Acked by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Akinobu Mita 提交于
This change makes the scsi disk driver handle the requests whose transfer length is greater than 0xffff with READ_16 or WRITE_16. However, this is a preparation for extending the data type of max_sectors in struct Scsi_Host and scsi_host_template. So, it is impossible to happen this condition for now, because SCSI low-level drivers can not specify max_sectors greater than 0xffff due to the data type limitation. Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Akinobu Mita 提交于
This prevents integer overflow when converting the request queue's max_sectors from sectors to bytes. However, this is a preparation for extending the data type of max_sectors in struct Scsi_Host and scsi_host_template. So, it is impossible to happen this integer overflow for now, because SCSI low-level drivers can not specify max_sectors greater than 0xffff due to the data type limitation. Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com> Acked by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Bart Van Assche 提交于
scsi_put_command() is either invoked before blk_start_request() or after block layer processing has completed. scsi_cmnd.abort_work is scheduled from inside the SCSI timeout handler. The block layer guarantees that either the regular completion handler (softirq_done_fn()) or the timeout handler (rq_timed_out_fn()) is invoked but not both. This means that scsi_put_command() is never invoked while abort_work is scheduled. Hence remove the cancel_delayed_work() call from scsi_put_command(). Similarly, scsi_abort_command() is only invoked from the SCSI timeout handler. If scsi_abort_command() is invoked for a SCSI command with the SCSI_EH_ABORT_SCHEDULED flag set this means that scmd_eh_abort_handler() has already invoked scsi_queue_insert() and hence that scsi_cmnd.abort_work is no longer pending. Hence also remove the cancel_delayed_work() call from scsi_abort_command(). Signed-off-by: NBart Van Assche <bvanassche@acm.org> Reviewed-by: NHannes Reinecke <hare@suse.de> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 James Bottomley 提交于
Flush commands don't transfer data and thus need to be special cased in the I/O completion handler so that we can propagate errors to the block layer and filesystem. Signed-off-by: NJames Bottomley <JBottomley@Parallels.com> Reported-by: NSteven Haber <steven@qumulo.com> Tested-by: NSteven Haber <steven@qumulo.com> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Cc: stable@vger.kernel.org Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
- 01 7月, 2014 1 次提交
-
-
由 Alan Stern 提交于
Some buggy JMicron USB-ATA bridges don't know how to translate the FUA bit in READs or WRITEs. This patch adds an entry in unusual_devs.h and a blacklist flag to tell the sd driver not to use FUA. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Reported-by: NMichael Büsch <m@bues.ch> Tested-by: NMichael Büsch <m@bues.ch> Acked-by: NJames Bottomley <James.Bottomley@HansenPartnership.com> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> CC: <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 25 6月, 2014 8 次提交
-
-
由 Paolo Bonzini 提交于
Even though the virtio-scsi spec guarantees that all requests related to the TMF will have been completed by the time the TMF itself completes, the request queue's callback might not have run yet. This causes requests to be completed more than once, and as a result triggers a variety of BUGs or oopses. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NVenkatesh Srinivas <venkateshs@google.com> Cc: stable@vger.kernel.org Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Paolo Bonzini 提交于
Calling the workqueue interface on uninitialized work items isn't a good idea even if they're zeroed. It's not failing catastrophically only through happy accidents. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Brian King 提交于
Add a memory barrier prior to sending a new command to the VIOS to ensure the VIOS does not receive stale data in the command buffer. Also add a memory barrier when processing the CRQ for completed commands. Signed-off-by: NBrian King <brking@linux.vnet.ibm.com> Acked-by: NNathan Fontenot <nfont@linux.vnet.ibm.com> Cc: stable@vger.kernel.org Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Brian King 提交于
If a CRQ reset is triggered for some reason while in the middle of performing VSCSI adapter initialization, we don't want to call the done function for the initialization MAD commands as this will only result in two threads attempting initialization at the same time, resulting in failures. Signed-off-by: NBrian King <brking@linux.vnet.ibm.com> Acked-by: NNathan Fontenot <nfont@linux.vnet.ibm.com> Cc: stable@vger.kernel.org Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Quinn Tran 提交于
Signed-off-by: NQuinn Tran <quinn.tran@qlogic.com> Signed-off-by: NSaurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Neil Horman 提交于
Recently had this warning reported: [ 290.489047] Call Trace: [ 290.489053] [<ffffffff8169efec>] dump_stack+0x19/0x1b [ 290.489055] [<ffffffff810ac7a9>] __might_sleep+0x179/0x230 [ 290.489057] [<ffffffff816a4ad5>] mutex_lock_nested+0x55/0x520 [ 290.489061] [<ffffffffa01b9905>] ? bnx2fc_l2_rcv_thread+0xc5/0x4c0 [bnx2fc] [ 290.489065] [<ffffffffa0174c1a>] fc_vport_id_lookup+0x3a/0xa0 [libfc] [ 290.489068] [<ffffffffa01b9a6c>] bnx2fc_l2_rcv_thread+0x22c/0x4c0 [bnx2fc] [ 290.489070] [<ffffffffa01b9840>] ? bnx2fc_vport_destroy+0x110/0x110 [bnx2fc] [ 290.489073] [<ffffffff8109e0cd>] kthread+0xed/0x100 [ 290.489075] [<ffffffff8109dfe0>] ? insert_kthread_work+0x80/0x80 [ 290.489077] [<ffffffff816b2fec>] ret_from_fork+0x7c/0xb0 [ 290.489078] [<ffffffff8109dfe0>] ? insert_kthread_work+0x80/0x80 Its due to the fact that we call a potentially sleeping function from the bnx2fc rcv path with preemption disabled (via the get_cpu call embedded in the per-cpu variable stats lookup in bnx2fc_l2_rcv_thread. Easy enough fix, we can just move the stats collection later in the function where we are sure we won't preempt or sleep. This also allows us to not have to enable pre-emption when doing a per-cpu lookup, since we're certain not to get rescheduled. Signed-off-by: NNeil Horman <nhorman@tuxdriver.com> Acked-by: NEddie Wai <eddie.wai@broadcom.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Maurizio Lombardi 提交于
In case of of error, the bnx2fc_cmd_mgr_alloc() function will call the bnx2fc_cmd_mgr_free() to perform the cleanup. The problem is that in one case the latter may try to scan some not-yet initialized lists, resulting in a kernel panic. This patch prevents this from happening by freeing the lists before calling bnx2fc_cmd_mgr_free(). Signed-off-by: NMaurizio Lombardi <mlombard@redhat.com> Acked-by: NEddie Wai <eddie.wai@broadcom.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Neil Horman 提交于
debugfs caught this: WARNING: at lib/debugobjects.c:260 debug_print_object+0x83/0xa0() ODEBUG: free active (active state 0) object type: work_struct hint: fc_scsi_scan_rport+0x0/0xd0 [scsi_transport_fc] CPU: 1 PID: 184 Comm: kworker/1:1 Tainted: G W -------------- 3.10.0-123.el7.x86_64.debug #1 Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 Workqueue: fc_wq_5 fc_rport_final_delete [scsi_transport_fc] Call Trace: [<ffffffff8169efec>] dump_stack+0x19/0x1b [<ffffffff8106cbd1>] warn_slowpath_common+0x61/0x80 [<ffffffff8106cc4c>] warn_slowpath_fmt+0x5c/0x80 [<ffffffff8133e003>] debug_print_object+0x83/0xa0 [<ffffffffa04e2f40>] ? fc_parse_wwn+0x100/0x100 [<ffffffff8133f23b>] debug_check_no_obj_freed+0x22b/0x270 [<ffffffffa04e127e>] ? fc_rport_dev_release+0x1e/0x30 [<ffffffff811db3e9>] kfree+0xd9/0x2d0 [<ffffffffa04e127e>] fc_rport_dev_release+0x1e/0x30 [<ffffffff81428032>] device_release+0x32/0xa0 [<ffffffff8132701e>] kobject_release+0x7e/0x1b0 [<ffffffff81326ed8>] kobject_put+0x28/0x60 [<ffffffff81428397>] put_device+0x17/0x20 [<ffffffffa04e5025>] fc_rport_final_delete+0x165/0x210 [<ffffffff810959b0>] process_one_work+0x220/0x710 [<ffffffff81095944>] ? process_one_work+0x1b4/0x710 [<ffffffff81095fbb>] worker_thread+0x11b/0x3a0 [<ffffffff81095ea0>] ? process_one_work+0x710/0x710 [<ffffffff8109e0cd>] kthread+0xed/0x100 [<ffffffff8109dfe0>] ? insert_kthread_work+0x80/0x80 [<ffffffff816b2fec>] ret_from_fork+0x7c/0xb0 [<ffffffff8109dfe0>] ? insert_kthread_work+0x80/0x80 Seems to be because the scan_work work_struct might be active when the housing fc_rport struct gets freed. Ensure that we cancel it prior to freeing the rport Signed-off-by: NNeil Horman <nhorman@tuxdriver.com> Reviewed-by: NVasu Dev <vasu.dev@intel.com> Reviewed-by: NHannes Reinecke <hare@suse.de> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-