- 11 Jul, 2018 7 commits
-
-
James Smart authored
Kernel occasionally crashed with the following ops on NVME Target: BUG: unable to handle kernel NULL pointer dereference at 0000000000000058 IP: [<ffffffffa042ee50>] lpfc_nvmet_defer_rcv+0x50/0x70 [lpfc] Callback routine was called for deferred rcv when it should be treated as a normal rcv. Added code in callback routine to detect this condition and log a message, then bail. Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
James Smart authored
Current implementation missed setting the duration field. Correct the code to set the field. Signed-off-by:
-
James Smart authored
The PBDE optimizations aren't supported in all firmware revs. Make optimizations configurable in case there's a side effect on old firmware. Signed-off-by:
-
James Smart authored
rmmod of driver hangs As driver instances were being unloaded, the NVME target port was unloaded first. During the unload, the NVME initiator port sent a heartbeat IO. Because of the target port state, that IO was scheduled for an Abort; however, that abort subsequently failed. The failure was not cleaned up properly and lpfc_sli4_xri_exchange_busy_wait silently hung forever. Clean failed abort properly and make lpfc_sli4_xri_exchange_busy_wait not hangs silently while waiting for aborts to complete. Signed-off-by:
-
James Smart authored
System crashes when the lpfc module is unloaded after making the port offline The nvme queue pointers were freed during port offline, but were later accessed in pci remove path. Validate the pointers in pci remove path before accessing them. Signed-off-by:
-
James Smart authored
Driver is incorrectly formatting a register on new hardware, using a format for an older chip. This can result in non-deterministic behavior. Ensure driver is not setting "workqueue index" in the WQ doorbell when making a non-dpp doorbell write. The field must be zero when non-dpp. Signed-off-by:
-
James Smart authored
Kernel crashes during fill_read_buffer when nvme_info sysfs file read. With multiple NVME targets, approx 40, nvme_info may grow larger than PAGE_SIZE bytes. snprintf(buf + len, PAGE_SIZE - len, ...) logic is flawed as PAGE_SIZE - len can be < 0 and is accepted by snprintf. This results in buffer overflow, and is detected with check from dev_attr_show and fill_read_buffer. Change to use scnprintf to a tmp array, before calling strlcat to ensure no buffer overflow over PAGE_SIZE bytes. Message "6314" created as a new message indicating when there is more nvme info, but is truncated to fit within PAGE_SIZE bytes. Signed-off-by:
-
- 02 Jul, 2018 25 commits
-
-
Bart Van Assche authored
se_dev_entry.ua_count is only used to check whether or not se_dev_entry.ua_list is empty. Use list_empty_careful() instead. Checking whether or not ua_list is empty without holding the lock that protects that list is fine because the code that dequeues from that list will check again whether or not that list is empty. Signed-off-by:
Bart Van Assche <bart.vanassche@wdc.com> Reviewed-by:
Mike Christie <mchristi@redhat.com> Cc: Mike Christie <mchristi@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.com> Signed-off-by:
-
Bart Van Assche authored
Send a valid ASC / ASCQ combination back to the initiator if a SCSI command is received after a LUN has been removed. This patch fixes the following call trace: WARNING: CPU: 0 PID: 4 at drivers/target/target_core_transport.c:3131 translate_sense_reason+0x164/0x190 [target_core_mod] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core] RIP: 0010:translate_sense_reason+0x164/0x190 [target_core_mod] Call Trace: transport_send_check_condition_and_sense+0x95/0x1c0 [target_core_mod] transport_generic_request_failure+0x102/0x270 [target_core_mod] transport_generic_new_cmd+0x138/0x340 [target_core_mod] transport_handle_cdb_direct+0x2f/0x80 [target_core_mod] target_submit_cmd_map_sgls+0x212/0x2a0 [target_core_mod] srpt_handle_new_iu+0x244/0x680 [ib_srpt] __ib_process_cq+0x6d/0xc0 [ib_core] ib_cq_poll_work+0x18/0x50 [ib_core] process_one_work+0x20b/0x6a0 worker_thread+0x35/0x380 kthread+0x117/0x130 ret_from_fork+0x24/0x30 Signed-off-by:
-
Bart Van Assche authored
Signed-off-by:
-
Bart Van Assche authored
This patch does not change any functionality. Signed-off-by:
-
Bart Van Assche authored
The code under the "release:" label can only be reached after se_cmd has been set to a non-NULL value. Hence remove the if (se_cmd) test. Keep the else-part since calling transport_generic_free_cmd() is not necessary for a command that has not been submitted to the core. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: 4d3895d5 ("target/tcm_loop: Merge struct tcm_loop_cmd and struct tcm_loop_tmr") Signed-off-by:
-
Bart Van Assche authored
Since most target drivers do not use the second fabric_make_tpg() argument ("group") and since it is trivial to derive the group pointer from the wwn pointer, do not pass the group pointer to fabric_make_tpg(). Signed-off-by: -
Bart Van Assche authored
Fixes: e48354ce ("iscsi-target: Add iSCSI fabric support for target v4.1") Signed-off-by:
-
Bart Van Assche authored
Instead of calling __iscsit_free_cmd() from inside iscsit_aborted_task() if a command has been aborted and from inside iscsit_free_cmd() if a command has not been aborted, call __iscsit_free_cmd() from inside lio_release_cmd(). The latter function is namely called for all commands once the reference count has dropped to zero. Signed-off-by:
-
Bart Van Assche authored
Instead of embedding the completion that is used for waiting for command completion in struct se_cmd, let the context that waits for command completion allocate it. This makes it possible to have a single code path for non-aborted and aborted commands in target_release_cmd_kref() and avoids that transport_generic_free_cmd() has to call cmd->se_tfo->release_cmd() directly. This patch does not change any functionality. Note: transport_generic_free_cmd() only waits until the se_cmd reference count has reached zero after it has set both CMD_T_FABRIC_STOP and CMD_T_ABORTED. Signed-off-by:
-
Bart Van Assche authored
Since target_wait_free_cmd() skips TMFs with no associated LUN, it is safe to call that function for such commands. Use this to simplify transport_generic_free_cmd(). The only functional change in this patch is that CMD_T_FABRIC_STOP gets set for TMFs with no associated LUN by transport_generic_free_cmd(). Signed-off-by:
-
Bart Van Assche authored
Move identical code outside an if/else statement. This patch does not change any functionality. Signed-off-by:
-
Bart Van Assche authored
For the two calls to transport_cmd_finish_abort() outside core_tmr_handle_tas_abort() it is guaranteed that CMD_T_TAS is not set. Use this property to fold core_tmr_handle_tas_abort() into transport_cmd_finish_abort(). This patch does not change any functionality. Signed-off-by:
-
Bart Van Assche authored
The code that can set CMD_T_TAS is executed by the same thread as the thread that executes core_tmr_handle_tas_abort(). That means that no locking is needed to check CMD_T_TAS from inside core_tmr_handle_tas_abort(). This patch does not change any functionality. Signed-off-by:
-
Bart Van Assche authored
Document those aspects of transport_cmd_check_stop_to_fabric() and transport_generic_free_cmd() of which it is nontrivial to derive these from their implementation. Signed-off-by:
-
Bart Van Assche authored
Target drivers must call target_sess_cmd_list_set_waiting() and target_wait_for_sess_cmds() before freeing a session. Since freeing a session is only safe after all commands that are associated with a session have finished, make target_wait_for_sess_cmds() also wait for commands that are being aborted. Instead of setting a flag in each pending command from target_sess_cmd_list_set_waiting() and waiting in target_wait_for_sess_cmds() on a per-command completion, only set a per-session flag in the former function and wait on a per-session completion in the latter function. This change is safe because once a SCSI initiator system has submitted a command a target system is always allowed to execute it to completion. See also commit 0f4a9431 ("target: Fix remote-port TMR ABORT + se_cmd fabric stop"). This patch is based on the following two patches: * Bart Van Assche, target: Simplify session shutdown code, February 19, 2015 (https://github.com/bvanassche/linux/commit/8df5463d7d7619f2f1b70cfe5172eaef0aa52815). * Christoph Hellwig, target: Rework session shutdown code, December 7, 2015 (http://thread.gmane.org/gmane.linux.scsi.target.devel/10695). Signed-off-by:
-
Bart Van Assche authored
Other than initializing xcopy_pt_sess.sess_wait_list, this patch does not change any functionality. Signed-off-by:
-
Bart Van Assche authored
Signed-off-by:
-
Bart Van Assche authored
This patch does not change any functionality but makes the next patch easier to read. Signed-off-by:
-
Bart Van Assche authored
The approach for adding a device to the devices_idr data structure and for removing it is as follows: * &dev->dev_group.cg_item is initialized before a device is added to devices_idr. * If the reference count of a device drops to zero then target_free_device() removes the device from devices_idr. * All devices_idr manipulations are protected by device_mutex. This means that increasing the reference count of a device is sufficient to prevent removal from devices_idr and also that it is safe access dev_group.cg_item for any device that is referenced by devices_idr. Use this to modify target_find_device() and target_for_each_device() such that these functions no longer introduce a dependency between device_mutex and the configfs root inode mutex. Note: it is safe to pass a NULL pointer to config_item_put() and also to config_item_get_unless_zero(). This patch prevents that lockdep reports the following complaint: ====================================================== WARNING: possible circular locking dependency detected 4.12.0-rc1-dbg+ #1 Not tainted ------------------------------------------------------ rmdir/12053 is trying to acquire lock: (device_mutex#2){+.+.+.}, at: [<ffffffffa010afce>] target_free_device+0xae/0xf0 [target_core_mod] but task is already holding lock: (&sb->s_type->i_mutex_key#14){++++++}, at: [<ffffffff811c5c30>] vfs_rmdir+0x50/0x140 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&sb->s_type->i_mutex_key#14){++++++}: lock_acquire+0x59/0x80 down_write+0x36/0x70 configfs_depend_item+0x3a/0xb0 [configfs] target_depend_item+0x13/0x20 [target_core_mod] target_xcopy_locate_se_dev_e4_iter+0x87/0x100 [target_core_mod] target_devices_idr_iter+0x16/0x20 [target_core_mod] idr_for_each+0x39/0xc0 target_for_each_device+0x36/0x50 [target_core_mod] target_xcopy_locate_se_dev_e4+0x28/0x80 [target_core_mod] target_xcopy_do_work+0x2e9/0xdd0 [target_core_mod] process_one_work+0x1ca/0x3f0 worker_thread+0x49/0x3b0 kthread+0x109/0x140 ret_from_fork+0x31/0x40 -> #0 (device_mutex#2){+.+.+.}: __lock_acquire+0x101f/0x11d0 lock_acquire+0x59/0x80 __mutex_lock+0x7e/0x950 mutex_lock_nested+0x16/0x20 target_free_device+0xae/0xf0 [target_core_mod] target_core_dev_release+0x10/0x20 [target_core_mod] config_item_put+0x6e/0xb0 [configfs] configfs_rmdir+0x1a6/0x300 [configfs] vfs_rmdir+0xb7/0x140 do_rmdir+0x1f4/0x200 SyS_rmdir+0x11/0x20 entry_SYSCALL_64_fastpath+0x23/0xc2 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&sb->s_type->i_mutex_key#14); lock(device_mutex#2); lock(&sb->s_type->i_mutex_key#14); lock(device_mutex#2); *** DEADLOCK *** 3 locks held by rmdir/12053: #0: (sb_writers#10){.+.+.+}, at: [<ffffffff811e223f>] mnt_want_write+0x1f/0x50 #1: (&sb->s_type->i_mutex_key#14/1){+.+.+.}, at: [<ffffffff811cb97e>] do_rmdir+0x15e/0x200 #2: (&sb->s_type->i_mutex_key#14){++++++}, at: [<ffffffff811c5c30>] vfs_rmdir+0x50/0x140 stack backtrace: CPU: 3 PID: 12053 Comm: rmdir Not tainted 4.12.0-rc1-dbg+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Call Trace: dump_stack+0x86/0xcf print_circular_bug+0x1c7/0x220 __lock_acquire+0x101f/0x11d0 lock_acquire+0x59/0x80 __mutex_lock+0x7e/0x950 mutex_lock_nested+0x16/0x20 target_free_device+0xae/0xf0 [target_core_mod] target_core_dev_release+0x10/0x20 [target_core_mod] config_item_put+0x6e/0xb0 [configfs] configfs_rmdir+0x1a6/0x300 [configfs] vfs_rmdir+0xb7/0x140 do_rmdir+0x1f4/0x200 SyS_rmdir+0x11/0x20 entry_SYSCALL_64_fastpath+0x23/0xc2 Signed-off-by: -
Bart Van Assche authored
Some target code uses config_item_name() while other code accesses .ci_name directly. Make the target code consistent by switching to config_item_name(). Signed-off-by:
-
Ming Lei authored
32872863 ("scsi: avoid to hold host-wide counter of host_busy for scsi_mq") adds one extra check on scsi_host_busy(shost) in scsi_host_queue_ready(), which is wrong and not necessary, can causes booting stall on LSI53c895A. So remove the check. Cc: Omar Sandoval <osandov@fb.com>, Cc: "Martin K. Petersen" <martin.petersen@oracle.com>, Cc: James Bottomley <james.bottomley@hansenpartnership.com>, Cc: Christoph Hellwig <hch@lst.de>, Cc: Don Brace <don.brace@microsemi.com> Cc: Kashyap Desai <kashyap.desai@broadcom.com> Cc: Mike Snitzer <snitzer@redhat.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Laurence Oberman <loberman@redhat.com> Cc: Bart Van Assche <bart.vanassche@wdc.com> Cc: Guenter Roeck <linux@roeck-us.net> Reported-by:
Guenter Roeck <linux@roeck-us.net> Fixes: 32872863 ("scsi: avoid to hold host-wide counter of host_busy for scsi_mq") Signed-off-by:
Ming Lei <ming.lei@redhat.com> Tested-by:
-
Bart Van Assche authored
In the scsi_transport_srp implementation it cannot be avoided to iterate over a klist from atomic context when using the legacy block layer instead of blk-mq. Hence this patch that makes it safe to use klists in atomic context. This patch avoids that lockdep reports the following: WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&(&k->k_lock)->rlock); local_irq_disable(); lock(&(&q->__queue_lock)->rlock); lock(&(&k->k_lock)->rlock); <Interrupt> lock(&(&q->__queue_lock)->rlock); stack backtrace: Workqueue: kblockd blk_timeout_work Call Trace: dump_stack+0xa4/0xf5 check_usage+0x6e6/0x700 __lock_acquire+0x185d/0x1b50 lock_acquire+0xd2/0x260 _raw_spin_lock+0x32/0x50 klist_next+0x47/0x190 device_for_each_child+0x8e/0x100 srp_timed_out+0xaf/0x1d0 [scsi_transport_srp] scsi_times_out+0xd4/0x410 [scsi_mod] blk_rq_timed_out+0x36/0x70 blk_timeout_work+0x1b5/0x220 process_one_work+0x4fe/0xad0 worker_thread+0x63/0x5a0 kthread+0x1c1/0x1e0 ret_from_fork+0x24/0x30 See also commit c9ddf734 ("scsi: scsi_transport_srp: Fix shost to rport translation"). Signed-off-by:Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Bart Van Assche authored
Since nr_bytes == blk_rq_bytes(rq) == rq->__data_len, the rq->__data_len = nr_bytes assignment does not modify the value of rq->__data_len. Hence remove that assignment. Note: the code in sd_done() that sets the residual to zero for zone report requests is not affected by this patch. Signed-off-by:
Damien Le Moal <damien.lemoal@wdc.com> Cc: Hannes Reinecke <hare@suse.com> Cc: Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
-
Dan Carpenter authored
The id_tbl->table pointer points to unsigned long so static checkers complain that instead of 4 we should be allocating sizeof(long) bytes. We're trying to allocate enough bits for the bitmap. The size variable is always 1024. (1024 / 32 * 4) is the same as (1024 / 64 * 8) so this doesn't change runtime, but this is the more idiomatic way to do it and makes the static checker happy. [mkp: typo] Signed-off-by:
Manish Rangankar <Manish.Rangankar@cavium.com> Signed-off-by:
-
Breno Leitao authored
Currently an open firmware property is copied into partition_name variable without keeping a room for \0. Later one, this variable (partition_name), which is 97 bytes long, is strncpyed into ibmvcsci_host_data->madapter_info->partition_name, which is 96 bytes long, possibly truncating it 'again' and removing the \0. This patch simply decreases the partition name to 96 and just copy using strlcpy() which guarantees that the string is \0 terminated. I think there is no issue if this there is a truncation in this very first copy, i.e, when the open firmware property is read and copied into the driver for the very first time; This issue also causes the following warning on GCC 8: drivers/scsi/ibmvscsi/ibmvscsi.c:281:2: warning: strncpy output may be truncated copying 96 bytes from a string of length 96 [-Wstringop-truncation] ... inlined from ibmvscsi_probe at drivers/scsi/ibmvscsi/ibmvscsi.c:2221:7: drivers/scsi/ibmvscsi/ibmvscsi.c:265:3: warning: strncpy specified bound 97 equals destination size [-Wstringop-truncation] CC: Bart Van Assche <bart.vanassche@wdc.com> CC: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by:
Breno Leitao <leitao@debian.org> Acked-by:
Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by:
-
- 26 Jun, 2018 8 commits
-
-
Mike Christie authored
Fix warning: smatch warnings: drivers/target/target_core_user.c:301 tcmu_genl_cmd_done() warn: KERN_* level not at start of string Signed-off-by:
-
Ming Lei authored
It isn't necessary to check the host depth in scsi_queue_rq() any more since it has been respected by blk-mq before calling scsi_queue_rq() via getting driver tag. Lots of LUNs may attach to same host and per-host IOPS may reach millions, so we should avoid expensive atomic operations on the host-wide counter in the IO path. This patch implements scsi_host_busy() via blk_mq_tagset_busy_iter() for reading the count of busy IOs for scsi_mq. It is observed that IOPS is increased by 15% in IO test on scsi_debug (32 LUNs, 32 submit queues, 1024 can_queue, libaio/dio) in a dual-socket system. [mkp: clarified commit message] Cc: Omar Sandoval <osandov@fb.com>, Cc: "Martin K. Petersen" <martin.petersen@oracle.com>, Cc: James Bottomley <james.bottomley@hansenpartnership.com>, Cc: Christoph Hellwig <hch@lst.de>, Cc: Don Brace <don.brace@microsemi.com> Cc: Kashyap Desai <kashyap.desai@broadcom.com> Cc: Mike Snitzer <snitzer@redhat.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Laurence Oberman <loberman@redhat.com> Cc: Bart Van Assche <bart.vanassche@wdc.com> Signed-off-by:
-
Ming Lei authored
No functional change. Just introduce scsi_host_busy() and replace the direct read of scsi_host->host_busy with this new API. Cc: Omar Sandoval <osandov@fb.com>, Cc: "Martin K. Petersen" <martin.petersen@oracle.com>, Cc: James Bottomley <james.bottomley@hansenpartnership.com>, Cc: Christoph Hellwig <hch@lst.de>, Cc: Don Brace <don.brace@microsemi.com> Cc: Kashyap Desai <kashyap.desai@broadcom.com> Cc: Mike Snitzer <snitzer@redhat.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Laurence Oberman <loberman@redhat.com> Cc: Bart Van Assche <bart.vanassche@wdc.com> Signed-off-by:
-
Bart Van Assche authored
Since blk_rq_bytes(req) returns req->__data_len, assigning that value to req->__data_len is superfluous. Hence remove that assignment. See also commit 5db44863 ("[SCSI] sd: Implement support for WRITE SAME"). Signed-off-by:
-
Bart Van Assche authored
This patch avoids that smatch reports the following warnings: drivers/scsi/qedi/qedi_fw_api.c:129: init_sqe() warn: inconsistent indenting drivers/scsi/qedi/qedi_fw_api.c:137: init_sqe() warn: inconsistent indenting Signed-off-by:
-
Johannes Thumshirn authored
Some drivers are ADDing the scsi command's result bytes instead of ORing them. While this can produce correct results it has unexpected side effects. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
-
Johannes Thumshirn authored
When evaluating a SCSI command's result using the field access macros, check for equality of the fields and not if a specific bit is set. This is a preparation patch, for reworking the results field in the SCSI command. Signed-off-by:
-
Douglas Gilbert authored
The scsi_io_completion function contains three BUG() and BUG_ON() calls. Replace them with WARN variants. Signed-off-by:
Douglas Gilbert <dgilbert@interlog.com> Reviewed-by:
-
