- 13 Apr, 2021 28 commits
-
-
Gustavo A. R. Silva authored
Fix the following out-of-bounds warnings by embedding existing struct htb_rel_query into struct mpt3_addnl_diag_query, instead of duplicating its members: include/linux/fortify-string.h:20:29: warning: '__builtin_memcpy' offset [19, 32] from the object at 'karg' is out of the bounds of referenced subobject 'buffer_rel_condition' with type 'short unsigned int' at offset 16 [-Warray-bounds] include/linux/fortify-string.h:22:29: warning: '__builtin_memset' offset [19, 32] from the object at 'karg' is out of the bounds of referenced subobject 'buffer_rel_condition' with type 'short unsigned int' at offset 16 [-Warray-bounds] The problem is that the original code is trying to copy data into a bunch of struct members adjacent to each other in a single call to memcpy(). All those members are exactly the same contained in struct htb_rel_query, so instead of duplicating them into struct mpt3_addnl_diag_query, replace them with new member rel_query of type struct htb_rel_query. So, now that this new object is introduced, memcpy() doesn't overrun the length of &karg.buffer_rel_condition, because the address of the new struct object _rel_query_ is used as destination, instead. The same issue is present when calling memset(), and it is fixed with this same approach. Below is a comparison of struct mpt3_addnl_diag_query, before and after this change (the size and cachelines remain the same): $ pahole -C mpt3_addnl_diag_query drivers/scsi/mpt3sas/mpt3sas_ctl.o struct mpt3_addnl_diag_query { struct mpt3_ioctl_header hdr; /* 0 12 */ uint32_t unique_id; /* 12 4 */ uint16_t buffer_rel_condition; /* 16 2 */ uint16_t reserved1; /* 18 2 */ uint32_t trigger_type; /* 20 4 */ uint32_t trigger_info_dwords[2]; /* 24 8 */ uint32_t reserved2[2]; /* 32 8 */ /* size: 40, cachelines: 1, members: 7 */ /* last cacheline: 40 bytes */ }; $ pahole -C mpt3_addnl_diag_query drivers/scsi/mpt3sas/mpt3sas_ctl.o struct mpt3_addnl_diag_query { struct mpt3_ioctl_header hdr; /* 0 12 */ uint32_t unique_id; /* 12 4 */ struct htb_rel_query rel_query; /* 16 16 */ uint32_t reserved2[2]; /* 32 8 */ /* size: 40, cachelines: 1, members: 4 */ /* last cacheline: 40 bytes */ }; Also, this helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Link: https://lore.kernel.org/lkml/60659889.bJJILx2THu3hlpxW%25lkp@intel.com/ Link: https://lore.kernel.org/r/20210401162054.GA397186@embeddedorBuild-tested-by:kernel test robot <lkp@intel.com> Reported-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Javed Hasan authored
Use devlink_health_report() to push error indications. Implement this in qede via a callback function to make it possible to reuse it for other drivers sitting on top of qed in future. Also remove forcible recovery trigger and put it as a normal devlink callback in qed module. This allows user to enable/disable it via: devlink health set pci/xxxx:xx:xx.x reporter fw_fatal auto_recover false Link: https://lore.kernel.org/r/20210331164917.24662-3-jhasan@marvell.comSigned-off-by:Javed Hasan <jhasan@marvell.com> Signed-off-by:
-
Javed Hasan authored
Devlink instance lifetime was linked to qed_dev object. That caused devlink to be recreated on each recovery. Change it by making higher level driver (qede) responsible for lifetime management. This way devlink survives recoveries. qede now stores devlink structure pointer as a part of its device object, devlink private data contains a linkage structure, qed_devlink. Link: https://lore.kernel.org/r/20210331164917.24662-2-jhasan@marvell.comSigned-off-by:
-
Sergey Shtylyov authored
The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #s), causing it to fail with -EINVAL (overridden by -ENODEV further below). Stop calling request_irq() with the invalid IRQ #s. Link: https://lore.kernel.org/r/8f4b8fa5-8251-b977-70a1-9099bcb4bb17@omprussia.ru Fixes: c27d85f3 ("[SCSI] SNI RM 53c710 driver") Signed-off-by:
Sergey Shtylyov <s.shtylyov@omprussia.ru> Signed-off-by:
-
Sergey Shtylyov authored
The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding the real error code. Stop calling request_irq() with the invalid IRQ #s. Link: https://lore.kernel.org/r/363eb4c8-a3bf-4dc9-2a9e-90f349030a15@omprussia.ru Fixes: 0bb67f18 ("[SCSI] sun3x_esp: convert to esp_scsi") Signed-off-by:
-
Sergey Shtylyov authored
The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding the real error code. Stop calling request_irq() with the invalid IRQ #s. Link: https://lore.kernel.org/r/594aa9ae-2215-49f6-f73c-33bd38989912@omprussia.ru Fixes: 352e921f ("[SCSI] jazz_esp: converted to use esp_core") Signed-off-by:
-
Sergey Shtylyov authored
Commit df2d8213 ("hisi_sas: use platform_get_irq()") failed to take into account that irq_of_parse_and_map() and platform_get_irq() have a different way of indicating an error: the former returns 0 and the latter returns a negative error code. Fix up the IRQ checks! Link: https://lore.kernel.org/r/810f26d3-908b-1d6b-dc5c-40019726baca@omprussia.ru Fixes: df2d8213 ("hisi_sas: use platform_get_irq()") Acked-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Sergey Shtylyov authored
The driver overrides the error codes returned by platform_get_irq() to -ENODEV, so if it returns -EPROBE_DEFER, the driver would fail the probe permanently instead of the deferred probing. Propagate the error code upstream as it should have been done from the start... Link: https://lore.kernel.org/r/420364ca-614a-45e3-4e35-0e0653c7bc53@omprussia.ru Fixes: 2953f850 ("[SCSI] ufs: use devres functions for ufshcd") Signed-off-by:
-
dingsenjie authored
Use DEFINE_SHOW_ATTRIBUTE() macro to simplify the code. Link: https://lore.kernel.org/r/20210331065326.18804-1-dingsenjie@163.comSigned-off-by:
dingsenjie <dingsenjie@yulong.com> Signed-off-by:
-
Ye Bin authored
There is a error message within devm_ioremap_resource() already, so remove the dev_err() call to avoid redundant error message. Link: https://lore.kernel.org/r/20210409075522.2111083-1-yebin10@huawei.comReported-by:
Hulk Robot <hulkci@huawei.com> Reviewed-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
Ye Bin <yebin10@huawei.com> Signed-off-by:
-
Luo Jiaxing authored
Add (pseudo) SAS address for ATA software reset failure log to assist in debugging. Link: https://lore.kernel.org/r/1617709711-195853-7-git-send-email-john.garry@huawei.comSigned-off-by:
Luo Jiaxing <luojiaxing@huawei.com> Signed-off-by:
-
Luo Jiaxing authored
If a channel interrupt occurs without any status bit set, the handler will return directly. However, if such redundant interrupts are received, it's better to check what happen, so add logs for this. Link: https://lore.kernel.org/r/1617709711-195853-6-git-send-email-john.garry@huawei.comSigned-off-by:
Yihang Li <liyihang6@hisilicon.com> Signed-off-by:
-
Jianqin Xie authored
The debugfs snapshot should be executed before the reset occurs to ensure that the register contents are saved properly. As such, it is incorrect to queue the debugfs dump when running a reset as the reset will occur prior to the snapshot work item is handler. Therefore, directly snapshot registers in the reset work handler. Link: https://lore.kernel.org/r/1617709711-195853-5-git-send-email-john.garry@huawei.comSigned-off-by:
Jianqin Xie <xiejianqin@hisilicon.com> Signed-off-by:
-
Xiang Chen authored
Function sas_unregister_ha() needs to be called to roll back if hisi_hba->hw->hw_init() fails in function hisi_sas_probe() or hisi_sas_v3_probe(). Make that change. Link: https://lore.kernel.org/r/1617709711-195853-4-git-send-email-john.garry@huawei.comSigned-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
-
Luo Jiaxing authored
To help debugging efforts, print the device SAS address for v3 hw erroneous completion log. Here is an example print: hisi_sas_v3_hw 0000:b4:02.0: erroneous completion iptt=2193 task=000000002b0c13f8 dev id=17 addr=570fd45f9d17b001 Link: https://lore.kernel.org/r/1617709711-195853-3-git-send-email-john.garry@huawei.comSigned-off-by:
-
Luo Jiaxing authored
The debugfs code has been relocated to v3 hw driver, so delete unused struct hisi_sas_hw function pointers snapshot_{prepare, restore}. Link: https://lore.kernel.org/r/1617709711-195853-2-git-send-email-john.garry@huawei.comSigned-off-by: -
Luo Jiaxing authored
checkpatch reports the following: ERROR: that open brace { should be on the previous line +static struct error_fw flash_error_table[] = +{ Fix a couple of instances of misplaced open bracket. Link: https://lore.kernel.org/r/1617886593-36421-3-git-send-email-luojiaxing@huawei.comAcked-by:Jack Wang <jinpu.wang@ionos.com> Signed-off-by:
-
Luo Jiaxing authored
checkpatch reports the following: ERROR: space prohibited before that ',' (ctx:WxW) +int pm8001_mpi_general_event(struct pm8001_hba_info *pm8001_ha , void *piomb); Remove unnecessary whitespace. Link: https://lore.kernel.org/r/1617886593-36421-2-git-send-email-luojiaxing@huawei.comAcked-by: -
Colin Ian King authored
The for-loop iterates with a u8 loop counter i and compares this with the loop upper limit of pm8001_ha->max_q_num which is a u32 type. There is a potential infinite loop if pm8001_ha->max_q_num is larger than the u8 loop counter. Fix this by making the loop counter the same type as pm8001_ha->max_q_num. [mkp: this is purely theoretical, max_q_num is currently limited to 64] Link: https://lore.kernel.org/r/20210407135840.494747-1-colin.king@canonical.com Fixes: 65df7d19 ("scsi: pm80xx: Fix chip initialization failure") Addresses-Coverity: ("Infinite loop") Reviewed-by:
Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Igor Pylypiv authored
mpi_uninit_check() is not being called in an atomic context. The only caller of mpi_uninit_check() is pm80xx_chip_soft_rst(). Callers of pm80xx_chip_soft_rst(): - pm8001_ioctl_soft_reset() - pm8001_pci_probe() - pm8001_pci_remove() - pm8001_pci_suspend() - pm8001_pci_resume() There was a similar fix for mpi_init_check() in commit d71023af ("scsi: pm80xx: Do not busy wait in MPI init check") Link: https://lore.kernel.org/r/20210406180534.1924345-3-ipylypiv@google.comReviewed-by:
Vishakha Channapattan <vishakhavc@google.com> Acked-by:
Igor Pylypiv <ipylypiv@google.com> Signed-off-by:
-
Igor Pylypiv authored
The mpi_uninit_check() takes longer for inbound doorbell register to be cleared. Increase the timeout substantially so that the driver does not fail to load. Previously, the inbound doorbell wait time was mistakenly increased in the mpi_init_check() instead of mpi_uninit_check(). It is okay to leave the mpi_init_check() wait time as-is as these are timeout values and if there is a failure, waiting longer is not an issue. Link: https://lore.kernel.org/r/20210406180534.1924345-2-ipylypiv@google.com Fixes: e90e2362 ("scsi: pm80xx: Increase timeout for pm80xx mpi_uninit_check") Reviewed-by:
-
Bodo Stroesser authored
Make data_pages_per_blk changeable similar to the way it is done for max_data_area_mb. One can change the value by typing: echo "data_pages_per_blk=N" >control The value is printed when doing: cat info In addition, a new readonly attribute 'data_pages_per_blk' returns the value on read. Link: https://lore.kernel.org/r/20210324195758.2021-7-bostroesser@gmail.comSigned-off-by:
Bodo Stroesser <bostroesser@gmail.com> Signed-off-by:
-
Bodo Stroesser authored
Replace DATA_PAGES_PER_BLK and DATA_BLOCK_SIZE with new struct elements tcmu_dev->data_pages_per_blk and tcmu_dev->data_blk_size. These new variables are still loaded with constant definition DATA_PAGES_PER_BLK_DEF (= 1) and DATA_PAGES_PER_BLK_DEF * PAGE_SIZE. There is no way yet to set the values via configfs. Link: https://lore.kernel.org/r/20210324195758.2021-6-bostroesser@gmail.comSigned-off-by:
-
Bodo Stroesser authored
There is only one caller of tcmu_get_block_page left. Since it is a one-liner, we can remove the function. Link: https://lore.kernel.org/r/20210324195758.2021-5-bostroesser@gmail.comSigned-off-by:
-
Bodo Stroesser authored
Change tcmu to support DATA_BLOCK_SIZE being a multiple of PAGE_SIZE. There are two reasons why one would like to have a bigger DATA_BLOCK_SIZE: 1) If userspace - e.g. due to data compression, encryption or deduplication - needs to have receive or transmit data in a consecutive buffer, we can define DATA_BLOCK_SIZE to the maximum size of a SCSI READ/WRITE to enforce that userspace sees just one consecutive buffer. That way we can avoid the need for doing data copy in userspace. 2) Using a bigger data block size can speed up command processing in tcmu. The number of free data blocks to look up in bitmap is reduced substantially. The lookup for data pages in radix_tree can be done more efficiently if there are multiple pages in a data block. The maximum number of IOVs to set up is lower so cmd entries in the ring become smaller. Link: https://lore.kernel.org/r/20210324195758.2021-4-bostroesser@gmail.comSigned-off-by: -
Bodo Stroesser authored
Rename some variables and definitions as a first preparation for DATA_BLOCK_SIZE != PAGE_SIZE and add the new DATA_PAGES_PER_BLK definition containing the number of pages per data block. Rename tcmu_try_get_block_page() to tcmu_try_get_data_page(). Keep name tcmu_get_block_page() since it will go away in a following commit when there is only one caller left. Subsequent commits will then add full support for DATA_PAGES_PER_BLK != 1, which also means DATA_BLOCK_SIZE = DATA_PAGES_PER_BLK * PAGE_SIZE Link: https://lore.kernel.org/r/20210324195758.2021-3-bostroesser@gmail.comSigned-off-by:
-
Bodo Stroesser authored
Some definitions and members of struct tcmu_dev had misleading names. Examples: - ring_size was used for the size of mailbox + cmd ring + data area - CMDR_SIZE was used for size of mailbox + cmd ring I added the new definition MB_CMDR_SIZE (mailbox + command ring), changed CMDR_SIZE to hold the size of the command ring only and replaced in struct tcmu_dev the member ring_size with mmap_pages, because the member is now used in tcmu_mmap() only, where we need page count, not size. I also added the new struct tcmu_dev member 'cmdr' which is used to replace some occurences of '(void *)mb + CMDR_OFF' with 'udev->cmdr' for better readability. Link: https://lore.kernel.org/r/20210324195758.2021-2-bostroesser@gmail.comSigned-off-by:
-
Martin K. Petersen authored
Resolve a couple of conflicts between the 5.12 fixes branch and the 5.13 staging tree (iSCSI target and UFS). Signed-off-by:
-
- 06 Apr, 2021 12 commits
-
-
Luo Jiaxing authored
checkpatch reported several whitespace errors. Fix them all. Link: https://lore.kernel.org/r/1616675396-6108-3-git-send-email-luojiaxing@huawei.comSigned-off-by:
-
Luo Jiaxing authored
checkpatch reported an error in sas_to_ata_err(). switch and case statements are incorrectly indented. Link: https://lore.kernel.org/r/1616675396-6108-2-git-send-email-luojiaxing@huawei.comSigned-off-by:
-
Tian Tao authored
Remove unnecessary include of linux/version.h. Link: https://lore.kernel.org/r/1617283618-19346-1-git-send-email-tiantao6@hisilicon.comSigned-off-by:
Tian Tao <tiantao6@hisilicon.com> Signed-off-by:
Zhiqi Song <songzhiqi1@huawei.com> Signed-off-by:
-
Wan Jiabing authored
struct bfa_fcs_s is declared twice. First is declared at line 50, remove the duplicate. struct bfa_fcs_fabric_s is defined at line 175, remove unnecessary declaration. Link: https://lore.kernel.org/r/20210401063535.992487-1-wanjiabing@vivo.comSigned-off-by:
Wan Jiabing <wanjiabing@vivo.com> Signed-off-by:
-
Gustavo A. R. Silva authored
Fix the following out-of-bounds warnings by enclosing some structure members into new structure objects upiu_req and upiu_rsp: include/linux/fortify-string.h:20:29: warning: '__builtin_memcpy' offset [29, 48] from the object at 'treq' is out of the bounds of referenced subobject 'req_header' with type 'struct utp_upiu_header' at offset 16 [-Warray-bounds] include/linux/fortify-string.h:20:29: warning: '__builtin_memcpy' offset [61, 80] from the object at 'treq' is out of the bounds of referenced subobject 'rsp_header' with type 'struct utp_upiu_header' at offset 48 [-Warray-bounds] arch/m68k/include/asm/string.h:72:25: warning: '__builtin_memcpy' offset [29, 48] from the object at 'treq' is out of the bounds of referenced subobject 'req_header' with type 'struct utp_upiu_header' at offset 16 [-Warray-bounds] arch/m68k/include/asm/string.h:72:25: warning: '__builtin_memcpy' offset [61, 80] from the object at 'treq' is out of the bounds of referenced subobject 'rsp_header' with type 'struct utp_upiu_header' at offset 48 [-Warray-bounds] Refactor the code by making it more structured. The problem is that the original code is trying to copy data into a bunch of struct members adjacent to each other in a single call to memcpy(). Now that a new struct _upiu_req_ enclosing all those adjacent members is introduced, memcpy() doesn't overrun the length of &treq.req_header, because the address of the new struct object _upiu_req_ is used as the destination, instead. The same problem is present when memcpy() overruns the length of the source &treq.rsp_header; in this case the address of the new struct object _upiu_rsp_ is used, instead. Also, this helps with the ongoing efforts to enable -Warray-bounds and avoid confusing the compiler. Link: https://github.com/KSPP/linux/issues/109 Link: https://lore.kernel.org/lkml/60640558.lsAxiK6otPwTo9rv%25lkp@intel.com/ Link: https://lore.kernel.org/r/20210331224338.GA347171@embeddedorReported-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
-
Yang Yingliang authored
The spinlock and list head of fnic_list are initialized statically. It is unnecessary to initialize them. Link: https://lore.kernel.org/r/20210330125911.1050879-1-yangyingliang@huawei.comReported-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
zhouchuangao authored
BUG_ON() uses unlikely in if() which can be optimized at compile time. Link: https://lore.kernel.org/r/1617108361-6870-1-git-send-email-zhouchuangao@vivo.comSigned-off-by:
zhouchuangao <zhouchuangao@vivo.com> Signed-off-by:
-
Sreekanth Reddy authored
While diag reset is in progress there is short duration where all access to controller's PCI config space from the host needs to be blocked. This is due to a hardware limitation of the IOC controllers. Block all access to controller's config space from userland applications by calling pci_cfg_access_lock() while diag reset is in progress and unlocking it again after the controller comes back to ready state. Link: https://lore.kernel.org/r/20210330105137.20728-1-sreekanth.reddy@broadcom.com Cc: stable@vger.kernel.org #v5.4.108+ Signed-off-by:
Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by:
-
Sreekanth Reddy authored
Covert ActiveCablePowerRequirement's value to target CPU endian before displaying it. Link: https://lore.kernel.org/r/20210330105106.20569-1-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
Whenever the driver is adding a vSES to virtual-phys list it is reinitializing the list head. Hence those vSES devices which were added previously are lost. Stop reinitializing the list every time a new vSES device is added. Link: https://lore.kernel.org/r/20210330105004.20413-1-sreekanth.reddy@broadcom.com Cc: stable@vger.kernel.org #v5.11.10+ Signed-off-by:
-
Konstantin Shelekhin authored
Create the device for the virtual LUN 0 using the DUMMY flag. This change makes it possible to remove some special-casing in the INQUIRY code. Link: https://lore.kernel.org/r/20210322200938.53300-3-k.shelekhin@yadro.comReviewed-by:
Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
Konstantin Shelekhin <k.shelekhin@yadro.com> Signed-off-by:
-
Konstantin Shelekhin authored
This commit adds the DUMMY flag to the rd_mcp backend that forces a logical unit to report itself as not connected device of an unknown type. Essentially this allows users to create devices identical to the device for the virtual LUN 0, making it possible to explicitly create a LUN 0 device and configure its WWNs (e.g. vendor or product name). Link: https://lore.kernel.org/r/20210322200938.53300-2-k.shelekhin@yadro.comReviewed-by:
-
