- 31 Jul, 2021 7 commits
-
-
James Smart authored
The lpfc_sli4_nvmet_xri_aborted() routine takes out the abts_buf_list_lock and traverses the buffer contexts to match the xri. Upon match, it then takes the context lock before potentially removing the context from the associated buffer list. This violates the lock hierarchy used elsewhere in the driver of locking context, then the abts_buf_list_lock - thus a possible deadlock. Resolve by: after matching, release the abts_buf_list_lock, then take the context lock, and if to be deleted from the list, retake the abts_buf_list_lock, maintaining lock hierarchy. This matches same list lock hierarchy as elsewhere in the driver Link: https://lore.kernel.org/r/20210730163309.25809-1-jsmart2021@gmail.comReported-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Colin Ian King authored
There are two spelling mistakes with the same triple l in alloc, one in a comment, the other in a ql_dbg() debug message. Fix them. Link: https://lore.kernel.org/r/20210729082413.4761-1-colin.king@canonical.comSigned-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Christoph Hellwig authored
Remove the amount of indirect calls by making the handler responsible for the entire execution of the request. Link: https://lore.kernel.org/r/20210729064845.1044147-5-hch@lst.deSigned-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Christoph Hellwig authored
Move the sg_timeout and sg_reserved_size fields into the bsg_device and scsi_device structures as they have nothing to do with generic block I/O. Note that these values are now separate for bsg vs. SCSI device node access, but that just matches how /dev/sg vs the other nodes has always behaved. Link: https://lore.kernel.org/r/20210729064845.1044147-4-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
This was used for the table based SCSI passthough permission checking that is gone now. Link: https://lore.kernel.org/r/20210729064845.1044147-3-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Use the per-device cdev_device_interface to store the bsg data in the char device inode, and thus remove the need to embedd the bsg_class_device structure in the request_queue. Link: https://lore.kernel.org/r/20210729064845.1044147-2-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
cdrom_read_cdda_bpc() relies on sending SCSI command to the low level driver using a REQ_OP_SCSI_IN request. This isn't generic block layer functionality, so move the actual low-level code into the sr driver and call it through a new read_cdda_bpc method in the cdrom_device_ops structure. With this the CDROM code does not have to pull in scsi_normalize_sense() and depend on CONFIG_SCSI_COMMON. Link: https://lore.kernel.org/r/20210730072752.GB23847%40lst.deTested-by:
Anders Roxell <anders.roxell@linaro.org> Signed-off-by:
-
- 29 Jul, 2021 24 commits
-
-
Christoph Hellwig authored
Just call scsi_ioctl() in sg as that has the same effect. Link: https://lore.kernel.org/r/20210724072033.1284840-25-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Split the SG_IO handler from the main scsi_ioctl() routine. Link: https://lore.kernel.org/r/20210724072033.1284840-24-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Split the SCSI_IOCTL_GET_IDLUN handler from the main scsi_ioctl() routine. Link: https://lore.kernel.org/r/20210724072033.1284840-23-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Factor out a helper for the various flavors of START STOP UNIT command ioctls. Link: https://lore.kernel.org/r/20210724072033.1284840-22-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Remove the comment above ioctl_internal_command() which doesn't document this function at all. Link: https://lore.kernel.org/r/20210724072033.1284840-21-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
CONFIG_BLK_SCSI_REQUEST is rather misnamed as it enables building a small amount of code shared by the SCSI initiator, target, and consumers of the scsi_request passthrough API. Rename it and also allow building it as a module. [mkp: add module license] Link: https://lore.kernel.org/r/20210724072033.1284840-20-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Merge the ioctl handling in block/scsi_ioctl.c into its only caller in drivers/scsi/scsi_ioctl.c. Link: https://lore.kernel.org/r/20210724072033.1284840-19-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Remove the separate command filter structure and just use a switch statement (which also cought two duplicate commands), return a bool and give the function a sensible name. Link: https://lore.kernel.org/r/20210724072033.1284840-18-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Move the SCSI command size table to common SCSI code. Link: https://lore.kernel.org/r/20210724072033.1284840-17-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Merge scsi_req_init() into its only caller. Link: https://lore.kernel.org/r/20210724072033.1284840-16-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Move the SCSI-specific bsg code in the SCSI midlayer instead of in the common bsg code. This just keeps the common bsg code block/ and also allows building it as a module. Link: https://lore.kernel.org/r/20210724072033.1284840-15-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Decouple bsg from scsi_cmd_ioctl(). This requires a small amount of code duplication, but will allow moving all SCSI ioctl handling into SCSI midlayer. Link: https://lore.kernel.org/r/20210724072033.1284840-14-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Return the max_sectors value in bytes. Lifted from scsi_ioctl.c. Link: https://lore.kernel.org/r/20210724072033.1284840-13-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Ensure SCSI ULD only has to call a single ioctl helper. This also adds a bunch of missing ioctls to the ch driver, and removes the need for a duplicate implementation of SCSI_IOCTL_SEND_COMMAND command. Link: https://lore.kernel.org/r/20210724072033.1284840-12-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Manually verify that the device is not a partition and the caller has admin privіleges at the beginning of the sr ioctl method and open code the trivial check for sd as well. Link: https://lore.kernel.org/r/20210724072033.1284840-11-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Open code scsi_cmd_blk_ioctl() in its two callers. Link: https://lore.kernel.org/r/20210724072033.1284840-10-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Only the sr driver can handle SCSI passthrough requests, so move the call to scsi_cmd_blk_ioctl() there. Link: https://lore.kernel.org/r/20210724072033.1284840-9-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Merge st_ioctl_common() into st_ioctl() and streamline the invocation of the common ioctl helpers. Link: https://lore.kernel.org/r/20210724072033.1284840-8-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Just handle the compat case in scsi_ioctl() using in_compat_syscall(). Link: https://lore.kernel.org/r/20210724072033.1284840-7-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Merge the native and compat ioctl handlers into a single one using in_compat_syscall(). Link: https://lore.kernel.org/r/20210724072033.1284840-6-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Merge the native and compat ioctl handlers into a single one using in_compat_syscall(). Link: https://lore.kernel.org/r/20210724072033.1284840-5-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Merge the native and compat ioctl handlers into a single one using in_compat_syscall(), and also simplify the calling conventions by merging sd_ioctl_common() into sd_ioctl(). Link: https://lore.kernel.org/r/20210724072033.1284840-4-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
Merge the native and compat ioctl handlers into a single one using in_compat_syscall(). Link: https://lore.kernel.org/r/20210724072033.1284840-3-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
SCSI_IOCTL_SEND_COMMAND has been deprecated longer than bsg exists and has been warning for just as long. More importantly it harcodes SCSI CDBs and thus will do the wrong thing on non-SCSI bsg nodes. Link: https://lore.kernel.org/r/20210724072033.1284840-2-hch@lst.de Fixes: aa387cc8 ("block: add bsg helper library") Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Acked-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
- 27 Jul, 2021 9 commits
-
-
Nilesh Javali authored
Link: https://lore.kernel.org/r/20210624052606.21613-12-njavali@marvell.comSigned-off-by:
Nilesh Javali <njavali@marvell.com> Signed-off-by:
-
Quinn Tran authored
Increment the command and the completion counts. Link: https://lore.kernel.org/r/20210624052606.21613-11-njavali@marvell.comSigned-off-by:
Quinn Tran <qutran@marvell.com> Signed-off-by:
-
Quinn Tran authored
Some FC adapters from Marvell offer the ability to encrypt data in flight (EDIF). This feature requires an application to act as an authenticator. After the completion of PLOGI, both sides have authenticated and PRLI completed, encrypted I/Os are allowed to proceed. - Use new firmware API to encrypt traffic on the wire - Add driver parameter to enable|disable EDIF feature # modprobe qla2xxx ql2xsecenable=1 Link: https://lore.kernel.org/r/20210624052606.21613-10-njavali@marvell.comReviewed-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Co-developed-by:
Larry Wisneski <Larry.Wisneski@marvell.com> Signed-off-by:
Duane Grigsby <duane.grigsby@marvell.com> Signed-off-by:
Rick Hicksted Jr <rhicksted@marvell.com> Signed-off-by:
-
Quinn Tran authored
Some FC adapters from Marvell offer the ability to encrypt data in flight (EDIF). This feature requires an application to act as an authenticator. During runtime, driver and authentication application need to stay in sync in terms of: Session being down|up, arrival of new authentication message (AUTH ELS) and SADB update completion. These events are queued up as doorbell to the authentication application. Application would read this doorbell on regular basis to stay up to date. Each SCSI host would have a separate doorbell queue. The doorbell interface can daisy chain a list of events for each read. Each event contains an event code + hint to help application steer the next course of action. Link: https://lore.kernel.org/r/20210624052606.21613-9-njavali@marvell.comReviewed-by:
-
Quinn Tran authored
Some FC adapters from Marvell offer the ability to encrypt data in flight (EDIF). This feature requires an application to act as an authenticator. There is no FC switch scan service that can indicate whether a device is secure or non-secure. In order to detect whether the remote port supports encrypted operation, driver must first do a PLOGI with the remote device. On completion of the PLOGI, driver will query firmware to see if the device supports secure login. To do that, driver + firmware must advertise the security bit via PLOGI's service parameter. The remote device shall respond using the same service parameter whether it supports it or not. Link: https://lore.kernel.org/r/20210624052606.21613-8-njavali@marvell.comReviewed-by:
-
Quinn Tran authored
Some FC adapters from Marvell offer the ability to encrypt data in flight (EDIF). This feature requires an application to act as an authenticator. On completion of the authentication process, the authentication application will notify driver on whether it is successful or not. In case of success, application will use the QL_VND_SC_AUTH_OK BSG call to tell driver to proceed to the PRLI phase. In case of failure, application will use the QL_VND_SC_AUTH_FAIL bsg call to tell driver to tear down the connection and retry. In the case where an existing session is active, the re-key process can fail. The session tear down ensures data is not further compromised. Link: https://lore.kernel.org/r/20210624052606.21613-7-njavali@marvell.comReviewed-by:
-
Quinn Tran authored
Some FC adapters from Marvell offer the ability to encrypt data in flight (EDIF). This feature requires an application to act as an authenticator. As part of the authentication process, the authentication application will generate a SADB entry (Security Association/SA, key, SPI value, etc). This SADB is then passed to driver to be programmed into hardware. There will be a pair of SADB's (Tx and Rx) for each connection. After some period, the application can choose to change the key. At that time, a new set of SADB pair is given to driver. The old set of SADB will be deleted. Add a new bsg call (QL_VND_SC_SA_UPDATE) to allow application to allow adding or deleting SADB entries. Driver will not keep the key in memory. It will pass it to HW. It is assumed that application will assign a unique SPI value to this SADB (SA + key). Driver + hardware will assign a handle to track this unique SPI/SADB. Link: https://lore.kernel.org/r/20210624052606.21613-6-njavali@marvell.comReviewed-by:
-
Quinn Tran authored
Some FC adapters from Marvell offer the ability to encrypt data in flight (EDIF). This feature requires an application to act as an authenticator. Once authentication messages sent from a remote device have arrived, each message is extracted and placed in a buffer for application to retrieve. The FC frame header will be stripped, leaving behind the AUTH ELS payload. It is up to the application to strip the AUTH ELS header to get to the actual authentication message. Link: https://lore.kernel.org/r/20210624052606.21613-5-njavali@marvell.comReviewed-by:
-
Quinn Tran authored
Some FC adapters from Marvell offer the ability to encrypt data in flight (EDIF). This feature requires an application to act as an authenticator. Add the ability for authentication application to send and retrieve messages as part of the authentication process via existing FC_BSG_HST_ELS_NOLOGIN BSG interface. To send a message, application is expected to format the data in the AUTH ELS format. Refer to FC-SP2 for details. If a message was received, application is required to reply with either a LS_ACC or LS_RJT complete the exchange using the same interface. Otherwise, remote device will treat it as a timeout. Link: https://lore.kernel.org/r/20210624052606.21613-4-njavali@marvell.comReviewed-by:
-
