- 18 May, 2018 28 commits
-
-
Steffen Maier authored
This reverts commit 2443c8b2 ("[SCSI] zfcp: Merge FCP task management setup with regular FCP command setup"), because this introduced a dependency on the unsuitable SCSI command for scsi_eh / TMF. Signed-off-by:
Steffen Maier <maier@linux.ibm.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Benjamin Block <bblock@linux.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Steffen Maier authored
Originally, I planned for TMF handling to have different context data in fsf_req->data depending on the TMF scope in fcp_cmnd->fc_tm_flags: * scsi_device if FCP_TMF_LUN_RESET, * zfcp_port if FCP_TMF_TGT_RESET. However, the FCP channel requires a valid LUN handle so we now use scsi_device as context data with any TMF for the time being. Regular SCSI I/O FCP requests continue using scsi_cmnd as req->data. Hence, the callers of zfcp_fsf_fcp_handler_common() must resolve req->data and pass scsi_device as common context. While at it, remove the detour zfcp_sdev->port->adapter and use the more direct req->adapter as elsewhere in this function already. Signed-off-by:
-
Steffen Maier authored
The SCSI command pointer passed to scsi_eh callbacks is just one arbitrary command of potentially many that are in the eh queue to be processed. The command is only used to indirectly pass the TMF scope in terms of SCSI ID/target and SCSI LUN for LUN reset. Hence, zfcp had filled in SCSI trace record fields which do not really belong to the TMF. This was confusing. Therefore, refactor the TMF tracing to work without SCSI command. Since the FCP channel always requires a valid LUN handle, we use SCSI device as common context for any TMF (even target reset). To make it even clearer, we set all bits to 1 for the fields, which do not belong to the TMF, to indicate that these fields are invalid. The old zfcp_dbf_scsi() became zfcp_dbf_scsi_common() to now handle both SCSI commands and TMFs. The old argument scsi_cmnd is now optional and can be NULL with TMFs. The new argument scsi_device is mandatory to carry context, as well as SCSI ID/target and SCSI LUN in case of TMFs. New example trace record formatted with zfcpdbf from s390-tools: Timestamp : ... Area : SCSI Subarea : 00 Level : 1 Exception : - CPU ID : .. Caller : 0x... Record ID : 1 Tag : [lt]r_.... Request ID : 0x<reqid> ID of FSF FCP request with TM flag For cases without FSF request: 0x0 for none (invalid) SCSI ID : 0x<scsi_id> SCSI ID/target denoting scope SCSI LUN : 0x<scsi_lun> SCSI LUN denoting scope SCSI LUN high : 0x<scsi_lun_high> SCSI LUN denoting scope SCSI result : 0xffffffff none (invalid) SCSI retries : 0xff none (invalid) SCSI allowed : 0xff none (invalid) SCSI scribble : 0xffffffffffffffff none (invalid) SCSI opcode : ffffffff ffffffff ffffffff ffffffff none (invalid) FCP rsp inf cod: 0x00 FCP_RSP info code of TMF FCP rsp IU : 00000000 00000000 00000100 00000000 ext FCP_RSP IU 00000000 00000008 ext FCP_RSP IU FCP rsp IU len : 32 FCP_RSP IU length Payload time : ... FCP rsp IU all : 00000000 00000000 00000100 00000000 full FCP_RSP IU 00000000 00000008 00000000 00000000 full FCP_RSP IU Signed-off-by: -
Steffen Maier authored
Example trace record formatted with zfcpdbf from s390-tools: Timestamp : ... Area : REC Subarea : 00 Level : 1 Exception : - CPU ID : .. Caller : 0x... Record ID : 1 ZFCP_DBF_REC_TRIG Tag : ....... LUN : 0x... WWPN : 0x... D_ID : 0x... Adapter status : 0x... Port status : 0x... LUN status : 0x... Ready count : 0x... Running count : 0x... ERP want : 0x0. ZFCP_ERP_ACTION_REOPEN_... ERP need : 0xc0 ZFCP_ERP_ACTION_NONE Signed-off-by:
-
Steffen Maier authored
That other commit introduced an inconsistency because it would trace on ERP_FAILED for all callers of port forced reopen triggers (not just terminate_rport_io), but it would not trace on ERP_FAILED for all callers of other ERP triggers such as adapter, port regular, LUN. Therefore, generalize that other commit. zfcp_erp_action_enqueue() already had two early outs which re-used the one zfcp_dbf_rec_trig() call. All ERP trigger functions finally run through zfcp_erp_action_enqueue(). So move the special handling for ZFCP_STATUS_COMMON_ERP_FAILED into zfcp_erp_action_enqueue() and add another early out with new trace marker for pseudo ERP need in this case. This removes all early returns from all ERP trigger functions so we always end up at zfcp_dbf_rec_trig(). Example trace record formatted with zfcpdbf from s390-tools: Timestamp : ... Area : REC Subarea : 00 Level : 1 Exception : - CPU ID : .. Caller : 0x... Record ID : 1 ZFCP_DBF_REC_TRIG Tag : ....... LUN : 0x... WWPN : 0x... D_ID : 0x... Adapter status : 0x... Port status : 0x... LUN status : 0x... Ready count : 0x... Running count : 0x... ERP want : 0x0. ZFCP_ERP_ACTION_REOPEN_... ERP need : 0xe0 ZFCP_ERP_ACTION_FAILED Signed-off-by:
-
Steffen Maier authored
For problem determination we always want to see when we were invoked on the terminate_rport_io callback whether we perform something or not. Temporal event sequence of interest with a long fast_io_fail_tmo of 27 sec: loose remote port t workqueue [s] zfcp_q_<dev> IRQ zfcperp<dev> === ================== =================== ============================ 0 recv RSCN q p.test_link_work block rport start fast_io_fail_tmo send ADISC ELS 4 recv ADISC fail block zfcp_port port forced reopen send open port 12 recv open port fail q p.gid_pn_work zfcp_erp_wakeup (zfcp_erp_wait would return) GID_PN fail Before this point, we got a SCSI trace with tag "sctrpi1" on fast_io_fail, e.g. with the typical 5 sec setting. port.status |= ERP_FAILED If fast_io_fail_tmo triggers after this point, we missed a SCSI trace. workqueue fc_dl_<host> ================== 27 fc_timeout_fail_rport_io fc_terminate_rport_io zfcp_scsi_terminate_rport_io zfcp_erp_port_forced_reopen _zfcp_erp_port_forced_reopen if (port.status & ERP_FAILED) return; Therefore, write a trace before above early return. Example trace record formatted with zfcpdbf from s390-tools: Timestamp : ... Area : REC Subarea : 00 Level : 1 Exception : - CPU ID : .. Caller : 0x... Record ID : 1 ZFCP_DBF_REC_TRIG Tag : sctrpi1 SCSI terminate rport I/O LUN : 0xffffffffffffffff none (invalid) WWPN : 0x<wwpn> D_ID : 0x<n_port_id> Adapter status : 0x... Port status : 0x... LUN status : 0x00000000 none (invalid) Ready count : 0x... Running count : 0x... ERP want : 0x03 ZFCP_ERP_ACTION_REOPEN_PORT_FORCED ERP need : 0xe0 ZFCP_ERP_ACTION_FAILED Signed-off-by: -
Steffen Maier authored
get_device() and its internally used kobject_get() only return NULL if they get passed NULL as argument. zfcp_get_port_by_wwpn() loops over adapter->port_list so the iteration variable port is always non-NULL. Struct device is embedded in struct zfcp_port so &port->dev is always non-NULL. This is the argument to get_device(). However, if we get an fc_rport in terminate_rport_io() for which we cannot find a match within zfcp_get_port_by_wwpn(), the latter can return NULL. v2.6.30 commit 70932935 ("[SCSI] zfcp: Fix oops when port disappears") introduced an early return without adding a trace record for this case. Even if we don't need recovery in this case, for debugging we should still see that our callback was invoked originally by scsi_transport_fc. Example trace record formatted with zfcpdbf from s390-tools: Timestamp : ... Area : REC Subarea : 00 Level : 1 Exception : - CPU ID : .. Caller : 0x... Record ID : 1 Tag : sctrpin SCSI terminate rport I/O, no zfcp port LUN : 0xffffffffffffffff none (invalid) WWPN : 0x<wwpn> WWPN D_ID : 0x<n_port_id> N_Port-ID Adapter status : 0x... Port status : 0xffffffff unknown (-1) LUN status : 0x00000000 none (invalid) Ready count : 0x... Running count : 0x... ERP want : 0x03 ZFCP_ERP_ACTION_REOPEN_PORT_FORCED ERP need : 0xc0 ZFCP_ERP_ACTION_NONE Signed-off-by:
-
Steffen Maier authored
If a SCSI device is deleted during scsi_eh host reset, we cannot get a reference to the SCSI device anymore since scsi_device_get returns !=0 by design. Assuming the recovery of adapter and port(s) was successful, zfcp_erp_strategy_followup_success() attempts to trigger a LUN reset for the half-gone SCSI device. Unfortunately, it causes the following confusing trace record which states that zfcp will do a LUN recovery as "ERP need" is ZFCP_ERP_ACTION_REOPEN_LUN == 1 and equals "ERP want". Old example trace record formatted with zfcpdbf from s390-tools: Tag: : ersfs_3 ERP, trigger, unit reopen, port reopen succeeded LUN : 0x<FCP_LUN> WWPN : 0x<WWPN> D_ID : 0x<N_Port-ID> Adapter status : 0x5400050b Port status : 0x54000001 LUN status : 0x40000000 ZFCP_STATUS_COMMON_RUNNING but not ZFCP_STATUS_COMMON_UNBLOCKED as it was closed on close part of adapter reopen ERP want : 0x01 ERP need : 0x01 misleading However, zfcp_erp_setup_act() returns NULL as it cannot get the reference. Hence, zfcp_erp_action_enqueue() takes an early goto out and _NO_ recovery actually happens. We always do want the recovery trigger trace record even if no erp_action could be enqueued as in this case. For other cases where we did not enqueue an erp_action, 'need' has always been zero to indicate this. In order to indicate above goto out, introduce an eyecatcher "flag" to mark the "ERP need" as 'not needed' but still keep the information which erp_action type, that zfcp_erp_required_act() had decided upon, is needed. 0xc_ is chosen to be visibly different from 0x0_ in "ERP want". New example trace record formatted with zfcpdbf from s390-tools: Tag: : ersfs_3 ERP, trigger, unit reopen, port reopen succeeded LUN : 0x<FCP_LUN> WWPN : 0x<WWPN> D_ID : 0x<N_Port-ID> Adapter status : 0x5400050b Port status : 0x54000001 LUN status : 0x40000000 ERP want : 0x01 ERP need : 0xc1 would need LUN ERP, but no action set up ^ Before v2.6.38 commit ae0904f6 ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.") we could detect this case because the "erp_action" field in the trace was NULL. The rework removed erp_action as argument and field from the trace. This patch here is for tracing. A fix to allow LUN recovery in the case at hand is a topic for a separate patch. See also commit fdbd1c5e ("[SCSI] zfcp: Allow running unit/LUN shutdown without acquiring reference") for a similar case and background info. Signed-off-by: -
Steffen Maier authored
We already have a SCSI trace for the end of abort and scsi_eh TMF. Due to zfcp_erp_wait() and fc_block_scsi_eh() time can pass between the start of our eh callback and an actual send/recv of an abort / TMF request. In order to see the temporal sequence including any abort / TMF send retries, add a trace before the above two blocking functions. This supports problem determination with scsi_eh and parallel zfcp ERP. No need to explicitly trace the beginning of our eh callback, since we typically can send an abort / TMF and see its HBA response (in the worst case, it's a pseudo response on dismiss all of adapter recovery, e.g. due to an FSF request timeout [fsrth_1] of the abort / TMF). If we cannot send, we now get a trace record for the first "abrt_wt" or "[lt]r_wait" which denotes almost the beginning of the callback. No need to explicitly trace the wakeup after the above two blocking functions because the next retry loop causes another trace in any case and that is sufficient. Example trace records formatted with zfcpdbf from s390-tools: Timestamp : ... Area : SCSI Subarea : 00 Level : 1 Exception : - CPU ID : .. Caller : 0x... Record ID : 1 Tag : abrt_wt abort, before zfcp_erp_wait() Request ID : 0x0000000000000000 none (invalid) SCSI ID : 0x<scsi_id> SCSI LUN : 0x<scsi_lun> SCSI LUN high : 0x<scsi_lun_high> SCSI result : 0x<scsi_result_of_cmd_to_be_aborted> SCSI retries : 0x<retries_of_cmd_to_be_aborted> SCSI allowed : 0x<allowed_retries_of_cmd_to_be_aborted> SCSI scribble : 0x<req_id_of_cmd_to_be_aborted> SCSI opcode : <CDB_of_cmd_to_be_aborted> FCP rsp inf cod: 0x.. none (invalid) FCP rsp IU : ... none (invalid) Timestamp : ... Area : SCSI Subarea : 00 Level : 1 Exception : - CPU ID : .. Caller : 0x... Record ID : 1 Tag : lr_wait LUN reset, before zfcp_erp_wait() Request ID : 0x0000000000000000 none (invalid) SCSI ID : 0x<scsi_id> SCSI LUN : 0x<scsi_lun> SCSI LUN high : 0x<scsi_lun_high> SCSI result : 0x... unrelated SCSI retries : 0x.. unrelated SCSI allowed : 0x.. unrelated SCSI scribble : 0x... unrelated SCSI opcode : ... unrelated FCP rsp inf cod: 0x.. none (invalid) FCP rsp IU : ... none (invalid) Signed-off-by:
-
Steffen Maier authored
For problem determination we need to see whether and why we were successful or not. This allows deduction of scsi_eh escalation. Example trace record formatted with zfcpdbf from s390-tools: Timestamp : ... Area : SCSI Subarea : 00 Level : 1 Exception : - CPU ID : .. Caller : 0x... Record ID : 1 Tag : schrh_r SCSI host reset handler result Request ID : 0x0000000000000000 none (invalid) SCSI ID : 0xffffffff none (invalid) SCSI LUN : 0xffffffff none (invalid) SCSI LUN high : 0xffffffff none (invalid) SCSI result : 0x00002002 field re-used for midlayer value: SUCCESS or in other cases: 0x2009 == FAST_IO_FAIL SCSI retries : 0xff none (invalid) SCSI allowed : 0xff none (invalid) SCSI scribble : 0xffffffffffffffff none (invalid) SCSI opcode : ffffffff ffffffff ffffffff ffffffff none (invalid) FCP rsp inf cod: 0xff none (invalid) FCP rsp IU : 00000000 00000000 00000000 00000000 none (invalid) 00000000 00000000 v2.6.35 commit a1dbfddd ("[SCSI] zfcp: Pass return code from fc_block_scsi_eh to scsi eh") introduced the first return with something other than the previously hardcoded single SUCCESS return path. Signed-off-by:Jens Remus <jremus@linux.ibm.com> Reviewed-by:
-
Uma Krishnan authored
Depending on the underlying transport, cxlflash has a dependency on either the CXL or OCXL drivers, which are enabled via their Kconfig option. Instead of having a module wide dependency on these config options, it is better to isolate the object modules that are dependent on the CXL and OCXL drivers and adjust the module dependencies accordingly. This commit isolates the object files that are dependent on CXL and/or OCXL. The cxl/ocxl fops used in the core driver are tucked under an ifdef to avoid compilation errors. Signed-off-by:
Uma Krishnan <ukrishn@linux.vnet.ibm.com> Acked-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Signed-off-by:
-
Uma Krishnan authored
As a staging cleanup to support transport specific builds of the cxlflash module, relocate device dependent assignments to header files. This will avoid littering the core driver with conditional compilation logic. Signed-off-by:
-
Uma Krishnan authored
The new header file, backend.h, that was recently added is missing the include guards. This commit adds the guards. Signed-off-by:
-
Matthew R. Ochs authored
AFUs can only process a single AFU command at a time. This is enforced with a global mutex situated within the AFU send routine. As this mutex has a global scope, it has the potential to unnecessarily block commands destined for other AFUs. Instead of using a global mutex, transition the mutex to be per-AFU. This will allow commands to only be blocked by siblings of the same AFU. Signed-off-by:
-
Uma Krishnan authored
When a superpipe process that makes use of virtual LUNs is terminated or killed abruptly, there is a possibility that the cxlflash driver could hang and deprive other operations on the adapter. The release fop registered to be invoked on a context close, detaches every LUN associated with the context. The underlying service to detach the LUN assumes it has been called with the read semaphore held, and releases the semaphore before any operation that could be time consuming. When invoked without holding the read semaphore, an opportunity is created for the semaphore's count to become negative when it is temporarily released during one of these potential lengthy operations. This negative count results in subsequent acquisition attempts taking forever, leading to the hang. To support the current design point of holding the semaphore on the ioctl() paths, the release fop should acquire it before invoking any ioctl services. Signed-off-by:
-
Uma Krishnan authored
The kernel log can get filled with debug messages from send_cmd_ioarrin() when dynamic debug is enabled for the cxlflash module and there is a lot of legacy I/O traffic. While these messages are necessary to debug issues that involve command tracking, the abundance of data can overwrite other useful data in the log. The best option available is to limit the messages that should serve most of the common use cases. Signed-off-by:
-
Uma Krishnan authored
The following Oops may be encountered if the device is reset, i.e. EEH recovery, while there is heavy I/O traffic: 59:mon> t [c000200db64bb680] c008000009264c40 cxlflash_queuecommand+0x3b8/0x500 [cxlflash] [c000200db64bb770] c00000000090d3b0 scsi_dispatch_cmd+0x130/0x2f0 [c000200db64bb7f0] c00000000090fdd8 scsi_request_fn+0x3c8/0x8d0 [c000200db64bb900] c00000000067f528 __blk_run_queue+0x68/0xb0 [c000200db64bb930] c00000000067ab80 __elv_add_request+0x140/0x3c0 [c000200db64bb9b0] c00000000068daac blk_execute_rq_nowait+0xec/0x1a0 [c000200db64bba00] c00000000068dbb0 blk_execute_rq+0x50/0xe0 [c000200db64bba50] c0000000006b2040 sg_io+0x1f0/0x520 [c000200db64bbaf0] c0000000006b2e94 scsi_cmd_ioctl+0x534/0x610 [c000200db64bbc20] c000000000926208 sd_ioctl+0x118/0x280 [c000200db64bbcc0] c00000000069f7ac blkdev_ioctl+0x7fc/0xe30 [c000200db64bbd20] c000000000439204 block_ioctl+0x84/0xa0 [c000200db64bbd40] c0000000003f8514 do_vfs_ioctl+0xd4/0xa00 [c000200db64bbde0] c0000000003f8f04 SyS_ioctl+0xc4/0x130 [c000200db64bbe30] c00000000000b184 system_call+0x58/0x6c When there is no room to send the I/O request, the cached room is refreshed by reading the memory mapped command room value from the AFU. The AFU register mapping is refreshed during a reset, creating a race condition that can lead to the Oops above. During a device reset, the AFU should not be unmapped until all the active send threads quiesce. An atomic counter, cmds_active, is currently used to track internal AFU commands and quiesce during reset. This same counter can also be used for the active send threads. Signed-off-by:
-
Xiaofei Tan authored
Currently we don't check that device is not gone before dereferencing its elements in the function hisi_sas_task_exec() (specifically, the DQ pointer). This patch fixes this issue by filling in the DQ pointer in hisi_sas_task_prep() after we check that the device pointer is still safe to reference. [mkp: typo] Signed-off-by:
Xiaofei Tan <tanxiaofei@huawei.com> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Xiang Chen authored
The IPTT of a slot is unique, and we currently use hisi_hba lock to protect it. Now slot is managed on hisi_sas_device.list, so use DQ lock to protect for allocating and freeing the slot. Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
-
Xiang Chen authored
Currently we lock the DQ to protect whole delivery process. So this stops us building slots for the same queue in parallel, and can affect performance. To optimise it, only lock the DQ during special periods, specifically when allocating a slot from the DQ and when delivering a slot to the HW. This approach is now safe, thanks to the previous patches to ensure that we always deliver a slot to the HW once allocated. Signed-off-by:
-
Xiang Chen authored
Currently we allocate the slot's memory buffer after allocating the DQ slot. To aid DQ lockout reduction, and allow slots to be built in parallel, move this step (which can fail) prior to allocating the slot. Also a stray spin_unlock_irqrestore() is removed from internal task exec function. Signed-off-by:
-
Xiang Chen authored
Since the task prep functions now should not fail, adjust the return types to void. In addition, some checks in the task prep functions are relocated to the main module; this is specifically the check for the number of elements in an sg list exceeded the HW SGE limit. Signed-off-by:
-
Xiang Chen authored
Currently we use DQ lock to protect delivery of DQ entry one by one. To optimise to allow more than one slot to be built for a single DQ in parallel, we need to remove the DQ lock when preparing slots, prior to delivery. To achieve this, we rearrange the slot build order to ensure that once we allocate a slot for a task, we do cannot fail to deliver the task. In this patch, we rearrange the slot building for SMP tasks to ensure that sg mapping part (which can fail) happens before we allocate the slot in the DQ. Signed-off-by:
-
Alim Akhtar authored
This makes ufshcd_config_pwr_mode non-static so that other vendors like exynos can use it. Signed-off-by:
Seungwon Jeon <essuuj@gmail.com> Signed-off-by:
Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by:
-
Alim Akhtar authored
Some host controllers don't support host controller enable via HCE. Signed-off-by:
-
Alim Akhtar authored
Some host controllers support interrupt aggregation but don't allow resetting counter and timer in software. Signed-off-by:
-
Alim Akhtar authored
In the right behavior, setting the bit to '0' indicates clear and '1' indicates no change. If host controller handles this the other way, UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR can be used. [mkp: typo] Signed-off-by:
"Asutosh Das (asd)" <asutoshd@codeaurora.org> Signed-off-by:
-
Kees Cook authored
On the quest to remove all VLAs from the kernel[1] this moves buffers off the stack. In the second instance, this collapses two separately allocated buffers into a single buffer, since they are used consecutively, which saves 256 bytes (QUERY_DESC_MAX_SIZE + 1) of stack space. [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.comSigned-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
-
- 15 May, 2018 5 commits
-
-
Luc Van Oostenryck authored
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, but the implementation in this driver returns an 'int'. Fix this by returning 'netdev_tx_t' in this driver too. Signed-off-by:
Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by:
-
Wen Xiong authored
This patch adds new adapter error log for P9 system with the new AZ SAS cable. Signed-off-by:
Wen Xiong <wenxiong@linux.vnet.ibm.com> Acked-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
-
Colin Ian King authored
Trivial fix to spelling mistake in esas2r_debug message. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Andrei Vagin authored
There are two advantages: * Direct I/O allows to avoid the write-back cache, so it reduces affects to other processes in the system. * Async I/O allows to handle a few commands concurrently. DIO + AIO shows a better perfomance for random write operations: Mode: O_DSYNC Async: 1 $ ./fio --bs=4K --direct=1 --rw=randwrite --ioengine=libaio --iodepth=64 --name=/dev/sda --runtime=20 --numjobs=2 WRITE: bw=45.9MiB/s (48.1MB/s), 21.9MiB/s-23.0MiB/s (22.0MB/s-25.2MB/s), io=919MiB (963MB), run=20002-20020msec Mode: O_DSYNC Async: 0 $ ./fio --bs=4K --direct=1 --rw=randwrite --ioengine=libaio --iodepth=64 --name=/dev/sdb --runtime=20 --numjobs=2 WRITE: bw=1607KiB/s (1645kB/s), 802KiB/s-805KiB/s (821kB/s-824kB/s), io=31.8MiB (33.4MB), run=20280-20295msec Known issue: DIF (PI) emulation doesn't work when a target uses async I/O, because DIF metadata is saved in a separate file, and it is another non-trivial task how to synchronize writing in two files, so that a following read operation always returns a consisten metadata for a specified block. Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org> Cc: Christoph Hellwig <hch@infradead.org> Cc: Bryant G. Ly <bryantly@linux.vnet.ibm.com> Tested-by:
Bryant G. Ly <bryantly@linux.vnet.ibm.com> Signed-off-by:
Andrei Vagin <avagin@openvz.org> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Mike Christie <mchristi@redhat.com> Signed-off-by:
-
Kees Cook authored
On the quest to remove all VLAs from the kernel[1] this rearranges the code to avoid a VLA warning under -Wvla (gcc doesn't recognize "const" variables as not triggering VLA creation). Additionally cleans up variable naming to avoid 80 character column limit. [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.comSigned-off-by:
Boaz Harrosh <ooo@electrozaur.com> Signed-off-by:
-
- 08 May, 2018 7 commits
-
-
Zhu Lingshan authored
use new netlink events helpers tcmu_netlink_init() and tcmu_netlink_send() to refactor netlink event attribute TCMU_ATTR_WRITECACHE(belongs to TCMU_CMD_RECONFIG_DEVICE) which is also emulate_write_cache in configFS. Removed tcmu_netlink_event() since we have new netlink events helpers now. Signed-off-by:
Zhu Lingshan <lszhu@suse.com> Acked-by:
-
Zhu Lingshan authored
use new netlink events helpers tcmu_netlink_init() and tcmu_netlink_send() to refactor netlink event attribute TCMU_ATTR_DEV_SIZE(belongs to TCMU_CMD_RECONFIG_DEVICE) which is also dev_size in configFS. Signed-off-by:
-
Zhu Lingshan authored
use new netlink events helpers tcmu_netlink_init() and tcmu_netlink_send() to refactor netlink event attribute TCMU_ATTR_DEV_CFG(belongs to TCMU_CMD_RECONFIG_DEVICE) which is also dev_config in configFS. Signed-off-by:
-
Zhu Lingshan authored
use new netlink events helpers tcmu_netlink_init() and tcmu_netlink_send() to refactor netlink event TCMU_CMD_REMOVED_DEVICE Signed-off-by:
-
Zhu Lingshan authored
use new netlink events helpers tcmu_netlink_init() and tcmu_netlink_send() to refactor netlink event TCMU_CMD_ADDED_DEVICE Signed-off-by:
-
Zhu Lingshan authored
Add new netlink events helpers tcmu_netlink_event_init() and tcmu_netlink_event_send(). These new functions intend to replace existing netlink events helper function tcmu_netlink_event(). The existing function tcmu_netlink_event() works well for events like TCMU_ADDED_DEVICE and TCMU_REMOVED_DEVICE which only has one netlink attribute. But if there is a command requires more than one attributes to send out, we have to use a struct to adapt the paremeter reconfig_data, it is hard to use one struct or a union in one struct to adapt every command with different attributes, it may get long and ugly. With the new two functions, we can call tcmu_netlink_event_init() to initialize a netlink event, then add all attributes we need by using nla_put_xxx(), at last use tcmu_netlink_event_send() to send it out. So that we don't need to use a long struct or union if we want to send mulitple attributes for different commands. [mkp: typos] Signed-off-by:
-
Wenwen Wang authored
In tw_chrdev_ioctl(), the length of the data buffer is firstly copied from the userspace pointer 'argp' and saved to the kernel object 'data_buffer_length'. Then a security check is performed on it to make sure that the length is not more than 'TW_MAX_IOCTL_SECTORS * 512'. Otherwise, an error code -EINVAL is returned. If the security check is passed, the entire ioctl command is copied again from the 'argp' pointer and saved to the kernel object 'tw_ioctl'. Then, various operations are performed on 'tw_ioctl' according to the 'cmd'. Given that the 'argp' pointer resides in userspace, a malicious userspace process can race to change the buffer length between the two copies. This way, the user can bypass the security check and inject invalid data buffer length. This can cause potential security issues in the following execution. This patch checks for capable(CAP_SYS_ADMIN) in tw_chrdev_open() to avoid the above issues. Signed-off-by:
Wenwen Wang <wang6495@umn.edu> Acked-by:
Adam Radford <aradford@gmail.com> Signed-off-by:
-
