The UFS driver has two driver-specific fault injection mechanisms
(trigger_eh and timeout). Each fault injection configuration can only be
specified by a module parameter and cannot be reconfigured without
reloading the driver. Also, each configuration is common to all HBAs.
This change adds the following subdirectories for each UFS HBA when
debugfs is enabled:
/sys/kernel/debug/ufshcd/<HBA>/timeout_inject
/sys/kernel/debug/ufshcd/<HBA>/trigger_eh_inject
Each fault injection attribute can be dynamically set per HBA by a
corresponding file in these directories.
This is tested with QEMU UFS devices.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Link: https://lore.kernel.org/r/20231118124443.1007116-1-akinobu.mita@gmail.com
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The mpt3sas_ctl_exit() should be called after communication with the
controller stops but currently it may cause false warnings about not
released memory. Fix this by letting mpt3sas_ctl_exit() handle misc driver
release per driver and release DMA in mpt3sas_ctl_release() per ioc.
Signed-off-by: Tomas Henzl <thenzl@redhat.com>
Link: https://lore.kernel.org/r/20231019153706.7967-1-thenzl@redhat.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
James Seo <james@equiv.tech> says:
Commit df8fc4e934 ("kbuild: Enable -fstrict-flex-arrays=3") has
resulted in the only arrays that UBSAN_BOUNDS considers unbounded
being trailing arrays declared with [] as the last member of a
struct. Unbounded trailing arrays declared with [1] are common in
mpt3sas, which is causing spurious warnings to appear in some
situations, e.g. when more than one physical disk is connected:
UBSAN: array-index-out-of-bounds in drivers/scsi/mpt3sas/mpt3sas_scsih.c:6810:36
index 1 is out of range for type 'MPI2_SAS_IO_UNIT0_PHY_DATA [1]'
which relates to this unbounded array access:
port_id = sas_iounit_pg0->PhyData[i].Port;
and is just one example of 10 similar warnings currently occurring for
me during boot.
This series converts most trailing arrays declared with [1] in mptsas
into proper C99 flexible array members. Those that are not unbounded
and really are fixed-length arrays of length 1 are left alone.
I didn't find any conversions that required further source edits
besides changing [1] to [], and everything seems to work with my
SAS2008-based add-in card, but please look things over in case I
missed something subtle.
Rounding out the series are some opportunistic cleanups.
The only dependency is that patch 7 ("Use struct_size() for struct
size calculations") depends on patches 3-5.
Link: https://lore.kernel.org/r/20230806170604.16143-1-james@equiv.tech
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Currently, the ras_fwlog_func sysfs parameter allows users to input a value
greater than three when selecting a PCI function to enable RAS fw logging
feature.
The user's input is sanity checked in lpfc_sli4_ras_init(), but allowing an
input greater than three doesn't make sense because the max number of ports
per HBA is four.
Change the allowable range from [0, 7] to [0, 3].
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20231031191224.150862-2-justintee8345@gmail.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
This pattern of strncpy(dest, src, strlen(src)) is extremely bug-prone.
This pattern basically never results in NUL-terminated destination
strings unless `dest` was zero-initialized. The current implementation
may be accidentally correct as tw_dev is zero-allocated via:
host = scsi_host_alloc(&driver_template, sizeof(TW_Device_Extension));
...
tw_dev = shost_priv(host);
... wherein scsi_host_alloc() zero-allocates host:
shost = kzalloc(sizeof(struct Scsi_Host) + privsize, GFP_KERNEL);
Also, further suggesting this change is worthwhile is another strscpy()
usage in 3w-9xxx.c:
strscpy(tw_dev->tw_compat_info.driver_version, TW_DRIVER_VERSION,
sizeof(tw_dev->tw_compat_info.driver_version));
Considering the above, a suitable replacement is strscpy() [2] due to
the fact that it guarantees NUL-termination on the destination buffer
without unnecessarily NUL-padding.
Let's not be accidentally correct, let's be definitely correct.
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 <justinstitt@google.com>
Link: https://lore.kernel.org/r/20231023-strncpy-drivers-scsi-3w-sas-c-v1-1-4c40a1e99dfc@google.com
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
mpt3sas_scsih.c:_scsih_scan_for_devices_after_reset() allocates and fetches
a MPI2_CONFIG_PAGE_RAID_VOL_0 struct (Mpi2RaidVolPage0_t) and a
MPI2_CONFIG_PAGE_RAID_VOL_1 struct (Mpi2RaidVolPage1_t), but does not
include the terminal flexible array members in the struct size
calculations, fetch those members, or otherwise use those members in any
way.
These dynamic allocations can be replaced with local variables.
Signed-off-by: James Seo <james@equiv.tech>
Link: https://lore.kernel.org/r/20230806170604.16143-13-james@equiv.tech
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
mpt3sas_base.c:_base_update_diag_trigger_pages() allocates and fetches a
MPI2_CONFIG_PAGE_SASIOUNIT_1 struct (Mpi2SasIOUnitPage_t), but does not
include the terminal flexible array member in the struct size calculation,
fetch that member, or otherwise use that member in any way.
This dynamic allocation can be replaced with a local variable.
Signed-off-by: James Seo <james@equiv.tech>
Link: https://lore.kernel.org/r/20230806170604.16143-12-james@equiv.tech
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The per-adapter struct (struct MPT3SAS_ADAPTER) contains a
MPI2_CONFIG_PAGE_IO_UNIT_8 (Mpi2IOUnitPage8_t) iounit_pg8 member that is
populated by mpt3sas_base.c:_base_static_config_pages().
As the name of that function indicates, the iounit_pg8 member represents a
static configuration page data structure that rarely changes, and is among
several such static config pages that are currently being fetched once per
adapter per init (or reset) and copied to the per-adapter struct for later
use.
However, unlike the other static config pages, the iounit_pg8 member is
never actually used outside of _base_static_config_pages(). Also,
Mpi2IOUnitPage8_t has a flexible array member, making its presence in the
_middle_ of the per-adapter struct rather strange.
Remove this member from the per-adapter struct and fix up the portion of
_base_static_config_pages() that uses it.
Signed-off-by: James Seo <james@equiv.tech>
Link: https://lore.kernel.org/r/20230806170604.16143-9-james@equiv.tech
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This terminal 1-length variable array can be directly converted into a C99
flexible array member.
As all users of MPI26_CONFIG_PAGE_PIOUNIT_1 (Mpi26PCIeIOUnitPage1_t) do not
use PhyData[], no further source changes are required to accommodate its
reduced sizeof():
- mpt3sas_config.c:mpt3sas_config_get_pcie_iounit_pg1() fetches a
Mpi26PCIeIOUnitPage1_t into a caller-provided buffer, and may fetch
and write PhyData[] into that buffer depending on its sz argument.
It has one caller:
- mpt3sas_base.c:_base_assign_fw_reported_qd() passes
sizeof(Mpi26PCIeIOUnitPage1_t) as sz, but does not use PhyData[].
Signed-off-by: James Seo <james@equiv.tech>
Link: https://lore.kernel.org/r/20230806170604.16143-7-james@equiv.tech
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This terminal 1-length variable array can be directly converted into a C99
flexible array member.
As all users of MPI2_CONFIG_PAGE_SASIOUNIT_1 (Mpi2SasIOUnitPage1_t) either
calculate its size without depending on its sizeof() or do not use
PhyData[], no further source changes are required:
- mpt3sas_config.c:mpt3sas_config_get_sas_iounit_pg1() fetches a
Mpi2SasIOUnitPage1_t into a caller-provided buffer, and may fetch and
write PhyData[] into that buffer depending on its sz argument. Its
callers:
- mpt3sas_base.c:_base_assign_fw_reported_qd() passes
sizeof(Mpi2SasIOUnitPage1_t) as sz, but does not use PhyData[].
- mpt3sas_base.c:mpt3sas_base_update_missing_delay(),
mpt3sas_scsih.c:_scsih_sas_host_add(),
mpt3sas_transport.c:_transport_phy_enable(), and
mpt3sas_transport.c:_transport_phy_speed() all calculate sz
independently of sizeof(Mpi2SasIOUnitPage1_t) and allocate a
suitable buffer before calling mpt3sas_config_get_sas_iounit_pg1()
and using PhyData[].
- mpt3sas_config.c:mpt3sas_config_set_sas_iounit_pg1() writes the contents
of a caller-provided buffer to the adapter, with the size of the write
depending on its sz argument. Its callers:
- mpt3sas_base.c:mpt3sas_base_update_missing_delay(),
mpt3sas_transport.c:_transport_phy_enable(), and
mpt3sas_transport.c:_transport_phy_speed() have all previously
called mpt3sas_config_get_sas_iounit_pg1() to obtain a
Mpi2SasIOUnitPage1_t, and are merely writing back this same
struct with the same previously calculated sz.
Signed-off-by: James Seo <james@equiv.tech>
Link: https://lore.kernel.org/r/20230806170604.16143-6-james@equiv.tech
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This terminal 1-length variable array can be directly converted into a C99
flexible array member.
As all users of MPI2_CONFIG_PAGE_SASIOUNIT_0 (Mpi2SasIOUnitPage0_t) either
calculate its size without depending on its sizeof() or do not use
PhyData[], no further source changes are required:
- mpt3sas_config.c:mpt3sas_config_get_number_hba_phys() fetches a
Mpi2SasIOUnitPage0_t for itself, but does not use PhyData[].
- mpt3sas_config.c:mpt3sas_config_get_sas_iounit_pg0() fetches a
Mpi2SasIOUnitPage0_t into a caller-provided buffer, and may fetch and
write PhyData[] into that buffer depending on its sz argument. Its
callers:
- mpt3sas_scsih.c:_scsih_update_vphys_after_reset(),
mpt3sas_scsih.c:_scsih_get_port_table_after_reset(),
mpt3sas_scsih.c:_scsih_sas_host_refresh(),
mpt3sas_scsih.c:_scsih_sas_host_add(), and
mpt3sas_transport.c:_transport_phy_enable() all calculate sz
independently of sizeof(Mpi2SasIOUnitPage0_t) and allocate a
suitable buffer before calling mpt3sas_config_get_sas_iounit_pg0()
and using PhyData[].
Signed-off-by: James Seo <james@equiv.tech>
Link: https://lore.kernel.org/r/20230806170604.16143-5-james@equiv.tech
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This terminal 1-length variable array can be directly converted into a C99
flexible array member.
As all users of MPI2_CONFIG_PAGE_RAID_VOL_0 (Mpi2RaidVolPage0_t) either
calculate its size without depending on its sizeof() or do not use
PhysDisk[], no further source changes are required:
- mpt3sas_config.c:mpt3sas_config_get_number_pds() fetches a
Mpi2RaidVolPage0_t for itself, but does not use PhysDisk[].
- mpt3sas_config.c:mpt3sas_config_get_raid_volume_pg0() fetches a
Mpi2RaidVolPage0_t into a caller-provided buffer, and may fetch and
write PhysDisk[] into that buffer depending on its sz argument. Its
callers:
- mpt3sas_scsih.c:scsih_get_resync(),
mpt3sas_scsih.c:scsih_get_state(),
mpt3sas_scsih.c:_scsih_search_responding_raid_devices(), and
mpt3sas_scsih.c:_scsih_scan_for_devices_after_reset() all pass
sizeof(Mpi2RaidVolPage0_t) as sz, but do not use PhysDisk[].
- mpt3sas_scsih.c:_scsih_get_volume_capabilities() and
mpt3sas_warpdrive.c:mpt3sas_init_warpdrive_properties()
both calculate sz independently of sizeof(Mpi2RaidVolPage0_t)
and allocate a suitable buffer before calling
mpt3sas_config_get_raid_volume_pg0() and using PhysDisk[].
Signed-off-by: James Seo <james@equiv.tech>
Link: https://lore.kernel.org/r/20230806170604.16143-4-james@equiv.tech
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This terminal 1-length variable array can be directly converted into a C99
flexible array member.
As all users of MPI2_CONFIG_PAGE_IO_UNIT_8 (Mpi2IOUnitPage8_t) do not use
Sensor[], no further source changes are required to accommodate its reduced
sizeof():
- mpt3sas_config.c:mpt3sas_config_get_iounit_pg8() fetches a
Mpi2IOUnitPage8_t into a caller-provided buffer, assuming
sizeof(Mpi2IOUnitPage8_t) as the buffer size. It has one caller:
- mpt3sas_base.c:_base_static_config_pages() passes the address of the
Mpi2IOUnitPage8_t iounit_pg8 member of the per-adapter struct (struct
MPT3SAS_ADAPTER *ioc) as the buffer. The assumed buffer size is
therefore correct.
However, the only subsequent use in mpt3sas of the thus populated
ioc->iounit_pg8 is a little further on in the same function, and this
use does not involve ioc->iounit_pg8.Sensor[].
Note that iounit_pg8 occurs in the middle of the per-adapter struct,
not at the end. The per-adapter struct is extensively used throughout
mpt3sas even if its iounit_pg8 member isn't, resulting in an
especially large amount of noise when comparing binary changes
attributable to this commit.
Signed-off-by: James Seo <james@equiv.tech>
Link: https://lore.kernel.org/r/20230806170604.16143-3-james@equiv.tech
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
These terminal 1-length variable arrays can be directly converted into C99
flexible array members without any binary changes.
In most cases, they belong to unused structs, or to structs used only by
unused code. The remaining few coincidentally have their sizes calculated
in roundabout ways that do not depend on the sizeof() their structs.
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: James Seo <james@equiv.tech>
Link: https://lore.kernel.org/r/20230806170604.16143-2-james@equiv.tech
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
