kernel/drivers/scsi/lpfc/lpfc_ct.c, branch linux-6.9.y

scsi: lpfc: Replace deprecated strncpy() with strscpy()

2024-02-27T02:18:52Z

strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. We expect ae->value_string to be NUL-terminated because there's a comment that says as much; these attr strings are also used with other string APIs, further cementing the fact. Now, the question of whether or not to NUL-pad the destination buffer: lpfc_fdmi_rprt_defer() initializes vports (all zero-initialized), then we call lpfc_fdmi_cmd() with each vport and a mask. Then, inside of lpfc_fdmi_cmd() we check each bit in the mask to invoke the proper callback. Importantly, the zero-initialized vport is passed in as the "attr" parameter. Seeing this: | struct lpfc_fdmi_attr_string *ae = attr; ... we can tell that ae->value_string is entirely zero-initialized. Due to this, NUL-padding is _not_ required as it would be redundant. Considering the above, a suitable replacement is strscpy() [2]. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt Link: https://lore.kernel.org/r/20240226-strncpy-drivers-scsi-lpfc-lpfc_ct-c-v2-1-2df2e46569b9@google.com Reviewed-by: Kees Cook Signed-off-by: Martin K. Petersen

scsi: lpfc: Copyright updates for 14.4.0.0 patches

2024-02-06T01:51:36Z

Update copyrights to 2024 for files modified in the 14.4.0.0 patch set. Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20240131185112.149731-18-justintee8345@gmail.com Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen

scsi: lpfc: Change lpfc_vport load_flag member into a bitmask

2024-02-06T01:51:36Z

In attempt to reduce the amount of unnecessary shost_lock acquisitions in the lpfc driver, change load_flag into an unsigned long bitmask and use clear_bit/test_bit bitwise atomic APIs instead of reliance on shost_lock for synchronization. Also, correct the test for FC_UNLOADING in lpfc_ct_handle_mibreq, which incorrectly tests vport->fc_flag rather than vport->load_flag. Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20240131185112.149731-16-justintee8345@gmail.com Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen

scsi: lpfc: Change lpfc_vport fc_flag member into a bitmask

2024-02-06T01:51:36Z

In attempt to reduce the amount of unnecessary shost_lock acquisitions in the lpfc driver, change fc_flag into an unsigned long bitmask and use clear_bit/test_bit bitwise atomic APIs instead of reliance on shost_lock for synchronization. Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20240131185112.149731-15-justintee8345@gmail.com Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen

scsi: lpfc: Protect vport fc_nodes list with an explicit spin lock

2024-02-06T01:51:36Z

In attempt to reduce the amount of unnecessary shost_lock acquisitions in the lpfc driver, replace shost_lock with an explicit fc_nodes_list_lock spinlock when accessing vport->fc_nodes lists. Although vport memory region is owned by shost->hostdata, it is driver private memory and an explicit fc_nodes list lock for fc_nodes list mutations is more appropriate than locking the entire shost. Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20240131185112.149731-14-justintee8345@gmail.com Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen

scsi: lpfc: Fix failure to delete vports when discovery is in progress

2024-02-06T01:51:35Z

Requests to delete an NPIV port may fail repeatedly if the initial request is received during discovery. If the FC_UNLOADING load_flag is set, then skip CT response processing for the physical port. This allows discovery processing for other lpfc_vport objects to reach their cmpl routines before deleting the vport. Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20240131185112.149731-8-justintee8345@gmail.com Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen

scsi: lpfc: Make fabric zone discovery more robust when handling unsolicited LOGO

2023-07-23T20:17:07Z

This patch provides better target rport recovery when a target rport is running in initiator mode to discover the fabric. Such a target will issue a LOGO before switching back to strict target mode and changes are made to recover the login. Log messages are also updated accordingly. Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20230712180522.112722-8-justintee8345@gmail.com Signed-off-by: Martin K. Petersen

scsi: lpfc: Use struct_size() helper

2023-06-08T01:20:21Z

Prefer struct_size() over open-coded versions of idiom: sizeof(struct-with-flex-array) + sizeof(typeof-flex-array-elements) * count where count is the max number of items the flexible array is supposed to contain. Link: https://github.com/KSPP/linux/issues/160 Co-developed-by: Gustavo A. R. Silva Signed-off-by: Gustavo A. R. Silva Co-developed-by: Kees Cook Signed-off-by: Kees Cook Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20230531223319.24328-1-justintee8345@gmail.com Reviewed-by: Kees Cook Signed-off-by: Martin K. Petersen

scsi: lpfc: Fix incorrect big endian type assignments in FDMI and VMID paths

2023-05-31T22:17:52Z

The kernel test robot reported sparse warnings regarding the improper usage of beXX_to_cpu() macros. Change the flagged FDMI and VMID member variables to __beXX and redo the beXX_to_cpu() macros appropriately. Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20230530191405.21580-1-justintee8345@gmail.com Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202305261159.lTW5NYrv-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202305260751.NWFvhLY5-lkp@intel.com/ Signed-off-by: Martin K. Petersen

scsi: lpfc: Replace one-element array with flexible-array member

2023-05-22T22:02:02Z

One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element arrays with flexible-array members in a couple of structures, and refactor the rest of the code, accordingly. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. This results in no differences in binary output. Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/295 Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1] Signed-off-by: Gustavo A. R. Silva Link: https://lore.kernel.org/r/6c6dcab88524c14c47fd06b9332bd96162656db5.1684358315.git.gustavoars@kernel.org Reviewed-by: Kees Cook Signed-off-by: Martin K. Petersen