kernel.git/drivers/scsi/fnic, branch linux-5.9.y

scsi: fnic: Use eth_broadcast_addr() to assign broadcast address

2020-07-25T02:09:56Z

Use eth_broadcast_addr() to assign broadcast address insetad of memset(). Link: https://lore.kernel.org/r/1595233498-13628-1-git-send-email-linmiaohe@huawei.com Signed-off-by: Miaohe Lin Signed-off-by: Martin K. Petersen

scsi: fnic: Use true, false for fnic->internal_reset_inprogress

2020-05-08T02:03:07Z

Fix the following coccicheck warning: drivers/scsi/fnic/fnic_scsi.c:2627:5-36: WARNING: Comparison of 0/1 to bool variable Link: https://lore.kernel.org/r/20200430121718.14970-1-yanaijie@huawei.com Signed-off-by: Jason Yan Signed-off-by: Martin K. Petersen

scsi: fnic: make vnic_wq_get_ctrl and vnic_wq_alloc_ring static

2020-04-17T17:48:05Z

Fix the following sparse warning: drivers/scsi/fnic/vnic_wq.c:28:5: warning: symbol 'vnic_wq_get_ctrl' was not declared. Should it be static? drivers/scsi/fnic/vnic_wq.c:40:5: warning: symbol 'vnic_wq_alloc_ring' was not declared. Should it be static? Link: https://lore.kernel.org/r/20200415093809.9365-3-yanaijie@huawei.com Reported-by: Hulk Robot Signed-off-by: Jason Yan Signed-off-by: Martin K. Petersen

scsi: fnic: make fnic_list and fnic_list_lock static

2020-04-17T17:48:04Z

Fix the following sparse warning: drivers/scsi/fnic/fnic_main.c:52:1: warning: symbol 'fnic_list' was not declared. Should it be static? drivers/scsi/fnic/fnic_main.c:53:1: warning: symbol 'fnic_list_lock' was not declared. Should it be static? Link: https://lore.kernel.org/r/20200415093809.9365-2-yanaijie@huawei.com Reported-by: Hulk Robot Signed-off-by: Jason Yan Signed-off-by: Martin K. Petersen

scsi: fnic: make some symbols static

2020-04-17T17:48:03Z

Fix the following sparse warning: drivers/scsi/fnic/vnic_dev.c:257:5: warning: symbol 'vnic_dev_cmd1' was not declared. Should it be static? drivers/scsi/fnic/vnic_dev.c:319:5: warning: symbol 'vnic_dev_cmd2' was not declared. Should it be static? drivers/scsi/fnic/vnic_dev.c:414:5: warning: symbol 'vnic_dev_init_devcmd1' was not declared. Should it be static? drivers/scsi/fnic/vnic_dev.c:425:5: warning: symbol 'vnic_dev_init_devcmd2' was not declared. Should it be static? drivers/scsi/fnic/vnic_dev.c:495:6: warning: symbol 'vnic_dev_deinit_devcmd2' was not declared. Should it be static? drivers/scsi/fnic/vnic_dev.c:506:5: warning: symbol 'vnic_dev_cmd_no_proxy' was not declared. Should it be static? Link: https://lore.kernel.org/r/20200415093809.9365-1-yanaijie@huawei.com Reported-by: Hulk Robot Signed-off-by: Jason Yan Signed-off-by: Martin K. Petersen

scsi: fnic: Use scnprintf() for avoiding potential buffer overflow

2020-03-17T17:36:10Z

Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Link: https://lore.kernel.org/r/20200315094241.9086-4-tiwai@suse.de Cc: "James E . J . Bottomley" Cc: "Martin K . Petersen" Cc: Satish Kharat Cc: Sesidhar Baddela Cc: Karan Tilak Kumar Cc: linux-scsi@vger.kernel.org Signed-off-by: Takashi Iwai Signed-off-by: Martin K. Petersen

scsi: Replace zero-length array with flexible-array member

2020-03-12T03:07:56Z

The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Link: https://lore.kernel.org/r/20200224161406.GA21454@embeddedor Reviewed-by: Lee Duncan Reviewed-by: Satish Kharat Signed-off-by: Gustavo A. R. Silva Signed-off-by: Martin K. Petersen

scsi: fnic: do not queue commands during fwreset

2020-01-21T04:58:14Z

When a link is going down the driver will be calling fnic_cleanup_io(), which will traverse all commands and calling 'done' for each found command. While the traversal is handled under the host_lock, calling 'done' happens after the host_lock is being dropped. As fnic_queuecommand_lck() is being called with the host_lock held, it might well be that it will pick the command being selected for abortion from the above routine and enqueue it for sending, but then 'done' is being called on that very command from the above routine. Which of course confuses the hell out of the scsi midlayer. So fix this by not queueing commands when fnic_cleanup_io is active. Link: https://lore.kernel.org/r/20200116102053.62755-1-hare@suse.de Signed-off-by: Hannes Reinecke Signed-off-by: Martin K. Petersen

scsi: fnic: fix invalid stack access

2020-01-16T03:59:59Z

gcc -O3 warns that some local variables are not properly initialized: drivers/scsi/fnic/vnic_dev.c: In function 'fnic_dev_hang_notify': drivers/scsi/fnic/vnic_dev.c:511:16: error: 'a0' is used uninitialized in this function [-Werror=uninitialized] vdev->args[0] = *a0; ~~~~~~~~~~~~~~^~~~~ drivers/scsi/fnic/vnic_dev.c:691:6: note: 'a0' was declared here u64 a0, a1; ^~ drivers/scsi/fnic/vnic_dev.c:512:16: error: 'a1' is used uninitialized in this function [-Werror=uninitialized] vdev->args[1] = *a1; ~~~~~~~~~~~~~~^~~~~ drivers/scsi/fnic/vnic_dev.c:691:10: note: 'a1' was declared here u64 a0, a1; ^~ drivers/scsi/fnic/vnic_dev.c: In function 'fnic_dev_mac_addr': drivers/scsi/fnic/vnic_dev.c:512:16: error: 'a1' is used uninitialized in this function [-Werror=uninitialized] vdev->args[1] = *a1; ~~~~~~~~~~~~~~^~~~~ drivers/scsi/fnic/vnic_dev.c:698:10: note: 'a1' was declared here u64 a0, a1; ^~ Apparently the code relies on the local variables occupying adjacent memory locations in the same order, but this is of course not guaranteed. Use an array of two u64 variables where needed to make it work correctly. I suspect there is also an endianness bug here, but have not digged in deep enough to be sure. Fixes: 5df6d737dd4b ("[SCSI] fnic: Add new Cisco PCI-Express FCoE HBA") Fixes: mmtom ("init/Kconfig: enable -O3 for all arches") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200107201602.4096790-1-arnd@arndb.de Signed-off-by: Arnd Bergmann Signed-off-by: Martin K. Petersen

scsi: fnic: fix use after free

2019-11-06T05:04:02Z

The memory chunk io_req is released by mempool_free. Accessing io_req->start_time will result in a use after free bug. The variable start_time is a backup of the timestamp. So, use start_time here to avoid use after free. Link: https://lore.kernel.org/r/1572881182-37664-1-git-send-email-bianpan2016@163.com Signed-off-by: Pan Bian Reviewed-by: Satish Kharat Signed-off-by: Martin K. Petersen