Don Brace <don.brace@microchip.com> says:
These patches are based on Martin Petersen's 6.11/scsi-queue tree
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git 6.11/scsi-queue
The functional changes of note to smartpqi are for: multipath failover
and improving the accuracy of our RAID bypass counter.
For multipath we are:
Reverting commit 94a68c8143 ("scsi: smartpqi: Quickly propagate
path failures to SCSI midlayer") because under certain rare
conditions involving encryption-enabled devices, a false path
failure is reported to the SML causing multipath to failover to
the other path.
Improving errors returned from the driver back to the SML by
checking for error codes returned from the firmware and returning
the correct ASC/ASCQ codes to the SML.
The other two patches add PCI-IDs for new controllers and change the
driver version.
Link: https://lore.kernel.org/r/20240711194704.982400-1-don.brace@microchip.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Update driver version to 2.1.28-025.
Reviewed-by: Mike Tran <mike.tran@microchip.com>
Reviewed-by: Gerry Morong <gerry.morong@microchip.com>
Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
Reviewed-by: Scott Teel <scott.teel@microchip.com>
Signed-off-by: Don Brace <don.brace@microchip.com>
Link: https://lore.kernel.org/r/20240711194704.982400-6-don.brace@microchip.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Improve multipath failovers by mapping firmware errors into I/O errors.
In some rare instances, firmware does not return the proper error code for
I/O errors caused by a multipath path failure.
Map I/O errors returned by firmware into errors that help the multipath
layer to detect the failure of a path.
Reviewed-by: Gerry Morong <gerry.morong@microchip.com>
Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
Reviewed-by: Scott Teel <scott.teel@microchip.com>
Reviewed-by: Mike McGowen <mike.mcgowen@microchip.com>
Signed-off-by: Kevin Barnett <kevin.barnett@microchip.com>
Signed-off-by: Don Brace <don.brace@microchip.com>
Link: https://lore.kernel.org/r/20240711194704.982400-5-don.brace@microchip.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Correct a rare multipath failure issue by reverting commit 94a68c8143
("scsi: smartpqi: Quickly propagate path failures to SCSI midlayer") [1].
Reason for revert: The patch propagated the path failure to SML quickly
when one of the path fails during IO and AIO path gets disabled for a
multipath device.
But it created a new issue: when creating a volume on an encryption-enabled
controller, the firmware reports the AIO path is disabled, which cause the
driver to report a path failure to SML for a multipath device.
There will be a new fix to handle "Illegal request" and "Invalid field in
parameter list" on RAID path when the AIO path is disabled on a multipath
device.
[1] https://lore.kernel.org/all/164375209313.440833.9992416628621839233.stgit@brunhilda.pdev.net/
Fixes: 94a68c8143 ("scsi: smartpqi: Quickly propagate path failures to SCSI midlayer")
Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
Reviewed-by: Scott Teel <scott.teel@microchip.com>
Reviewed-by: Mike McGowen <mike.mcgowen@microchip.com>
Signed-off-by: Gilbert Wu <Gilbert.Wu@microchip.com>
Signed-off-by: Don Brace <don.brace@microchip.com>
Link: https://lore.kernel.org/r/20240711194704.982400-4-don.brace@microchip.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The original implementation of this counter used an atomic variable.
However, this implementation negatively impacted performance in some
configurations.
Switch to using per_cpu variables.
Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
Reviewed-by: Scott Teel <scott.teel@microchip.com>
Reviewed-by: Mike McGowen <mike.mcgowen@microchip.com>
Co-developed-by: Mahesh Rajashekhara <mahesh.rajashekhara@microchip.com>
Signed-off-by: Mahesh Rajashekhara <mahesh.rajashekhara@microchip.com>
Signed-off-by: Kevin Barnett <kevin.barnett@microchip.com>
Signed-off-by: Don Brace <don.brace@microchip.com>
Link: https://lore.kernel.org/r/20240711194704.982400-3-don.brace@microchip.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
There is a scenario where a large number of discard commands are issued
when the iscsi initiator connects to the target and then performs a session
rescan operation. There is a time window, most of the commands are in UNMAP
mode, and some discard commands become WRITE SAME with UNMAP.
The discard mode has been negotiated during the SCSI probe. If the mode is
temporarily changed from UNMAP to WRITE SAME with UNMAP, an I/O ERROR may
occur because the target may not implement WRITE SAME with UNMAP. Keep the
discard mode stable to fix this issue.
Signed-off-by: Li Feng <fengli@smartx.com>
Link: https://lore.kernel.org/r/20240718080751.313102-2-fengli@smartx.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Justin Tee <justintee8345@gmail.com> says:
Update lpfc to revision 14.4.0.4
This patch set contains diagnostic logging improvements, a minor clean
up when submitting abort requests, a bug fix related to reset and
errata paths, and modifications to FLOGI and PRLO ELS command
handling.
The patches were cut against Martin's 6.11/scsi-queue tree.
Link: https://lore.kernel.org/r/20240726231512.92867-1-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
A kref imbalance occurs when handling an unsolicited PRLO in direct
attached topology.
Rework PRLO rcv handling when in MAPPED state. Save the state that we were
handling a PRLO by setting nlp_last_elscmd to ELS_CMD_PRLO. Then in the
lpfc_cmpl_els_logo_acc() completion routine, manually restart discovery.
By issuing the PLOGI, which nlp_gets, before nlp_put at the end of the
lpfc_cmpl_els_logo_acc() routine, we are saving us from a final nlp_put.
And, we are still allowing the unreg_rpi to happen.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20240726231512.92867-7-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In direct attached topology, certain target vendors that are quick to issue
FLOGI followed by a cable pull for more than dev_loss_tmo may result in a
kref imbalance for the remote port ndlp object.
Add an nlp_get when the defer_flogi_acc flag is set. This is expected to
balance the nlp_put in the defer_flogi_acc clause in the
lpfc_issue_els_flogi() routine. Because we need to retain the ndlp ptr,
reorganize all of the defer_flogi_acc information into one
lpfc_defer_flogi_acc struct.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20240726231512.92867-6-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The vport->vmid_flag is unintentionally cleared twice after an issue_lip
via the lpfc_reinit_vmid routine().
The first call to lpfc_reinit_vmid() is in lpfc_cmpl_els_flogi(). Then
lpfc_cmpl_els_flogi_fabric() calls lpfc_register_new_vport(), which calls
lpfc_cmpl_reg_new_vport() when the mbox command completes and calls
lpfc_reinit_vmid() a second time.
Fix by moving the vmid_flag clear outside of the lpfc_reinit_vmid() routine
so that vmid_flag is only cleared once upon FLOGI completion.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20240726231512.92867-5-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When the HBA is undergoing a reset or is handling an errata event, NULL ptr
dereference crashes may occur in routines such as
lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or
lpfc_abort_handler().
Add NULL ptr checks before dereferencing hdwq pointers that may have been
freed due to operations colliding with a reset or errata event handler.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20240726231512.92867-4-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The lpfc_sli_issue_abort_iotag() routine has a redundant assignment of
abtsiocbp->vport = vport;
The duplicate lines are from a previous refactoring, and this patch removes
the accidental redundancy.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20240726231512.92867-3-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
During diagnostics, it has been determined that the 0115 log message for
receipt of unknown ELS cmds does not benefit from trace buffer dumps. The
trace buffer dump floods the console with unnecessary information, and the
singular LOG_ELS flag has proven more beneficial in debugging efforts when
dealing with unknown ELS cmds.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20240726231512.92867-2-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The default UIC command timeout still remains 500ms. Allow platform
drivers to override the UIC command timeout if desired.
In a real product, the 500ms timeout value is probably good enough.
However, during the product development where there are a lot of logging
and debug messages being printed to the UART console, interrupt starvations
happen occasionally because the UART may print long debug messages from
different modules in the system. While printing, the UART may have
interrupts disabled for more than 500ms, causing UIC command timeout. The
UIC command timeout would trigger more printing from the UFS driver, and
eventually a watchdog timeout may occur unnecessarily.
Add support for overriding the UIC command timeout value with the newly
created uic_cmd_timeout kernel module parameter. Default value is
500ms. Supported values range from 500ms to 2 seconds.
Signed-off-by: Bao D. Nguyen <quic_nguyenb@quicinc.com>
Link: https://lore.kernel.org/r/e4e1c87f3f867f270a3d4b5d57a00139ff0e9741.1721792309.git.quic_nguyenb@quicinc.com
Suggested-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Replace the deprecated[1] use of 1-element arrays in struct sgmap, struct
sgmap64, struct sgmapraw, struct user_sgmap, and struct user_sgmap64 with
modern flexible arrays. Additionally remove struct user_sgmapraw as it is
unused.
The resulting binary output differences from this change are limited only
to stack space consumption of the smaller "srbu" variable in
aac_issue_safw_bmic_identify() and aac_get_safw_ciss_luns(), as well as the
smaller associated pair of memcpy()s in
aac_send_safw_bmic_cmd(). Artificially growing the size of srbu back to its
prior size removes all binary differences[2].
As an aside, after studying the aacraid driver code I wonder how
aac_send_wellness_command() ever works. It is reporting a size 4 bytes too
small for what it has constructed in memory in the DMA region: sgentry64 is
size 12, whereas sgentry is size 8. Perhaps the hardware doesn't
care. (Regardless, it is unchanged by this patch.)
Link: https://github.com/KSPP/linux/issues/79 [1]
Link: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=dev/v6.10-rc2/1-element&id=45e6226bcbc5e982541754eca7ac29f403e82f5e [2]
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20240711215739.208776-2-kees@kernel.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
struct aac_srb_unit contains struct aac_srb, which contains struct sgmap,
which ends in a (currently) "fake" (1-element) flexible array. Converting
this to a flexible array is needed so that runtime bounds checking won't
think the array is fixed size (i.e. under CONFIG_FORTIFY_SOURCE=y and/or
CONFIG_UBSAN_BOUNDS=y), as other parts of aacraid use struct sgmap as a
flexible array.
It is not legal to have a flexible array in the middle of a structure, so
it either needs to be split up or rearranged so that it is at the end of
the structure. Luckily, struct aac_srb_unit, which is exclusively
consumed/updated by aac_send_safw_bmic_cmd(), does not depend on member
ordering.
The values set in the on-stack struct aac_srb_unit instance "srbu" by the
only two callers, aac_issue_safw_bmic_identify() and
aac_get_safw_ciss_luns(), do not contain anything in srbu.srb.sgmap.sg, and
they both implicitly initialize srbu.srb.sgmap.count to 0 during
memset(). For example:
memset(&srbu, 0, sizeof(struct aac_srb_unit));
srbcmd = &srbu.srb;
srbcmd->flags = cpu_to_le32(SRB_DataIn);
srbcmd->cdb[0] = CISS_REPORT_PHYSICAL_LUNS;
srbcmd->cdb[1] = 2; /* extended reporting */
srbcmd->cdb[8] = (u8)(datasize >> 8);
srbcmd->cdb[9] = (u8)(datasize);
rcode = aac_send_safw_bmic_cmd(dev, &srbu, phys_luns, datasize);
During aac_send_safw_bmic_cmd(), a separate srb is mapped into DMA, and has
srbu.srb copied into it:
srb = fib_data(fibptr);
memcpy(srb, &srbu->srb, sizeof(struct aac_srb));
Only then is srb.sgmap.count written and srb->sg populated:
srb->count = cpu_to_le32(xfer_len);
sg64 = (struct sgmap64 *)&srb->sg;
sg64->count = cpu_to_le32(1);
sg64->sg[0].addr[1] = cpu_to_le32(upper_32_bits(addr));
sg64->sg[0].addr[0] = cpu_to_le32(lower_32_bits(addr));
sg64->sg[0].count = cpu_to_le32(xfer_len);
But this is happening in the DMA memory, not in srbu.srb. An attempt to
copy the changes back to srbu does happen:
/*
* Copy the updated data for other dumping or other usage if
* needed
*/
memcpy(&srbu->srb, srb, sizeof(struct aac_srb));
But this was never correct: the sg64 (3 u32s) overlap of srb.sg (2 u32s)
always meant that srbu.srb would have held truncated information and any
attempt to walk srbu.srb.sg.sg based on the value of srbu.srb.sg.count
would result in attempting to parse past the end of srbu.srb.sg.sg[0] into
srbu.srb_reply.
After getting a reply from hardware, the reply is copied into
srbu.srb_reply:
srb_reply = (struct aac_srb_reply *)fib_data(fibptr);
memcpy(&srbu->srb_reply, srb_reply, sizeof(struct aac_srb_reply));
This has always been fixed-size, so there's no issue here. It is worth
noting that the two callers _never check_ srbu contents -- neither
srbu.srb nor srbu.srb_reply is examined. (They depend on the mapped
xfer_buf instead.)
Therefore, the ordering of members in struct aac_srb_unit does not matter,
and the flexible array member can moved to the end.
(Additionally, the two memcpy()s that update srbu could be entirely
removed as they are never consumed, but I left that as-is.)
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20240711215739.208776-1-kees@kernel.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Kees Cook <kees@kernel.org> says:
Replace all remaining uses of deprecated 1-element "fake" flexible
arrays with modern C99 flexible arrays. Add __counted_by annotations
at the same time.
Link: https://lore.kernel.org/r/20240711172432.work.523-kees@kernel.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Replace the deprecated[1] use of a 1-element array in struct
_CONFIG_PAGE_IOC_4 with a modern flexible array.
Additionally add __counted_by annotation since SEP is only ever accessed
after updating ACtiveSEP:
lsi/mpi_cnfg.h: IOC_4_SEP SEP[] __counted_by(ActiveSEP); /* 08h */
mptsas.c: ii = IOCPage4Ptr->ActiveSEP++;
mptsas.c: IOCPage4Ptr->SEP[ii].SEPTargetID = id;
mptsas.c: IOCPage4Ptr->SEP[ii].SEPBus = channel;
No binary differences are present after this conversion.
Link: https://github.com/KSPP/linux/issues/79 [1]
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20240711172821.123936-6-kees@kernel.org
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Replace the deprecated[1] use of a 1-element array in struct
_CONFIG_PAGE_IOC_3 with a modern flexible array.
Additionally add __counted_by annotation since PhysDisk is only ever
accessed via a loops bounded by NumPhysDisks:
lsi/mpi_cnfg.h: IOC_3_PHYS_DISK PhysDisk[] __counted_by(NumPhysDisks); /* 08h */
mptscsih.c: for (i = 0; i < ioc->raid_data.pIocPg3->NumPhysDisks; i++) {
mptscsih.c: if ((id == ioc->raid_data.pIocPg3->PhysDisk[i].PhysDiskID) &&
mptscsih.c: (channel == ioc->raid_data.pIocPg3->PhysDisk[i].PhysDiskBus)) {
mptscsih.c: for (i = 0; i < ioc->raid_data.pIocPg3->NumPhysDisks; i++) {
mptscsih.c: ioc->raid_data.pIocPg3->PhysDisk[i].PhysDiskNum);
mptscsih.c: ioc->raid_data.pIocPg3->PhysDisk[i].PhysDiskNum,
mptscsih.c: for (i = 0; i < ioc->raid_data.pIocPg3->NumPhysDisks; i++) {
mptscsih.c: if ((id == ioc->raid_data.pIocPg3->PhysDisk[i].PhysDiskID) &&
mptscsih.c: (channel == ioc->raid_data.pIocPg3->PhysDisk[i].PhysDiskBus)) {
mptscsih.c: rc = ioc->raid_data.pIocPg3->PhysDisk[i].PhysDiskNum;
mptscsih.c: for (i = 0; i < ioc->raid_data.pIocPg3->NumPhysDisks; i++) {
mptscsih.c: ioc->raid_data.pIocPg3->PhysDisk[i].PhysDiskNum);
mptscsih.c: ioc->raid_data.pIocPg3->PhysDisk[i].PhysDiskNum,
No binary differences are present after this conversion.
Link: https://github.com/KSPP/linux/issues/79 [1]
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20240711172821.123936-5-kees@kernel.org
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Replace the deprecated[1] use of a 1-element array in struct
_CONFIG_PAGE_IOC_2 with a modern flexible array.
Additionally add __counted_by annotation since RaidVolume is only ever
accessed from loops controlled by NumActiveVolumes:
lsi/mpi_cnfg.h: CONFIG_PAGE_IOC_2_RAID_VOL RaidVolume[] __counted_by(NumActiveVolumes); /* 0Ch */
mptbase.c: for (i = 0; i < pIoc2->NumActiveVolumes ; i++)
mptbase.c: pIoc2->RaidVolume[i].VolumeBus,
mptbase.c: pIoc2->RaidVolume[i].VolumeID);
mptsas.c: for (i = 0; i < ioc->raid_data.pIocPg2->NumActiveVolumes; i++) {
mptsas.c: RaidVolume[i].VolumeID) {
mptsas.c: RaidVolume[i].VolumeBus;
mptsas.c: for (i = 0; i < ioc->raid_data.pIocPg2->NumActiveVolumes; i++) {
mptsas.c: ioc->raid_data.pIocPg2->RaidVolume[i].VolumeID, 0);
mptsas.c: ioc->raid_data.pIocPg2->RaidVolume[i].VolumeID);
mptsas.c: ioc->raid_data.pIocPg2->RaidVolume[i].VolumeID, 0);
mptsas.c: for (i = 0; i < ioc->raid_data.pIocPg2->NumActiveVolumes; i++) {
mptsas.c: if (ioc->raid_data.pIocPg2->RaidVolume[i].VolumeID ==
mptsas.c: for (i = 0; i < ioc->raid_data.pIocPg2->NumActiveVolumes; i++)
mptsas.c: if (ioc->raid_data.pIocPg2->RaidVolume[i].VolumeID == id)
mptspi.c: for (i=0; i < ioc->raid_data.pIocPg2->NumActiveVolumes; i++) {
mptspi.c: if (ioc->raid_data.pIocPg2->RaidVolume[i].VolumeID == id) {
No binary differences are present after this conversion.
Link: https://github.com/KSPP/linux/issues/79 [1]
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20240711172821.123936-4-kees@kernel.org
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Replace the deprecated[1] use of a 1-element array in struct
_CONFIG_PAGE_RAID_PHYS_DISK_1 with a modern flexible array.
Additionally add __counted_by annotation since Path is only ever accessed
via a loops bounded by NumPhysDiskPaths:
lsi/mpi_cnfg.h: RAID_PHYS_DISK1_PATH Path[] __counted_by(NumPhysDiskPaths);/* 0Ch */
mptbase.c: phys_disk->NumPhysDiskPaths = buffer->NumPhysDiskPaths;
mptbase.c: for (i = 0; i < phys_disk->NumPhysDiskPaths; i++) {
mptbase.c: phys_disk->Path[i].PhysDiskID = buffer->Path[i].PhysDiskID;
mptbase.c: phys_disk->Path[i].PhysDiskBus = buffer->Path[i].PhysDiskBus;
No binary differences are present after this conversion.
Link: https://github.com/KSPP/linux/issues/79 [1]
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20240711172821.123936-3-kees@kernel.org
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Replace the deprecated[1] use of a 1-element array in struct
_CONFIG_PAGE_SAS_IO_UNIT_0 with a modern flexible array.
Additionally add __counted_by annotation since PhyData is only ever
accessed via a loops bounded by NumPhys:
lsi/mpi_cnfg.h: MPI_SAS_IO_UNIT0_PHY_DATA PhyData[] __counted_by(NumPhys); /* 10h */
mptsas.c: port_info->num_phys = buffer->NumPhys;
mptsas.c: for (i = 0; i < port_info->num_phys; i++) {
mptsas.c: mptsas_print_phy_data(ioc, &buffer->PhyData[i]);
mptsas.c: port_info->phy_info[i].phy_id = i;
mptsas.c: port_info->phy_info[i].port_id =
mptsas.c: buffer->PhyData[i].Port;
mptsas.c: port_info->phy_info[i].negotiated_link_rate =
mptsas.c: buffer->PhyData[i].NegotiatedLinkRate;
No binary differences are present after this conversion.
Link: https://github.com/KSPP/linux/issues/79 [1]
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20240711172821.123936-2-kees@kernel.org
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Replace the deprecated[1] use of a 1-element array in struct
_RAID_VOL0_SETTINGS with a modern flexible array.
Additionally add __counted_by annotation since PhysDisk is only ever
accessed via a loops bounded by NumPhysDisks:
lsi/mpi_cnfg.h: RAID_VOL0_PHYS_DISK PhysDisk[] __counted_by(NumPhysDisks); /* 28h */
mptbase.c: for (i = 0; i < buffer->NumPhysDisks; i++) {
mptbase.c: buffer->PhysDisk[i].PhysDiskNum, &phys_disk) != 0)
mptsas.c: for (i = 0; i < buffer->NumPhysDisks; i++) {
mptsas.c: buffer->PhysDisk[i].PhysDiskNum, &phys_disk) != 0)
mptsas.c: for (i = 0; i < buffer->NumPhysDisks; i++) {
mptsas.c: buffer->PhysDisk[i].PhysDiskNum, &phys_disk) != 0)
No binary differences are present after this conversion.
Link: https://github.com/KSPP/linux/issues/79 [1]
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20240711172821.123936-1-kees@kernel.org
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Replace the deprecated[1] use of a 1-element arrays in struct
ipr_hostrcb_fabric_desc and struct ipr_hostrcb64_fabric_desc with modern
flexible arrays.
No binary differences are present after this conversion.
Link: https://github.com/KSPP/linux/issues/79 [1]
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20240711180702.work.536-kees@kernel.org
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Replace the deprecated[1] use of a 1-element array in struct
aac_ciss_phys_luns_resp with a modern flexible array.
No binary differences are present after this conversion.
Link: https://github.com/KSPP/linux/issues/79 [1]
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20240711175055.work.928-kees@kernel.org
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Replace the deprecated[1] use of a 1-element array in union aac_init with a
modern flexible array.
Additionally add __counted_by annotation since rrq is only ever accessed
after rr_queue_count has been set (with the same value used to control the
loop):
init->r8.rr_queue_count = cpu_to_le32(dev->max_msix);
...
for (i = 0; i < dev->max_msix; i++) {
addr = (u64)dev->host_rrq_pa + dev->vector_cap * i *
sizeof(u32);
init->r8.rrq[i].host_addr_high = cpu_to_le32(
upper_32_bits(addr));
No binary differences are present after this conversion.
Link: https://github.com/KSPP/linux/issues/79 [1]
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20240711174815.work.689-kees@kernel.org
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Replace the deprecated[1] use of a 1-element array in struct
MR_HOST_DEVICE_LIST with a modern flexible array.
One binary difference appears in megasas_host_device_list_query():
struct MR_HOST_DEVICE_LIST *ci;
...
ci = instance->host_device_list_buf;
...
memset(ci, 0, sizeof(*ci));
The memset() clears only the non-flexible array fields. Looking at the rest
of the function, this appears to be fine: firmware is using this region to
communicate with the kernel, so it likely never made sense to clear the
first MR_HOST_DEVICE_LIST_ENTRY.
Link: https://github.com/KSPP/linux/issues/79 [1]
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20240711155841.work.839-kees@kernel.org
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Replace the deprecated[1] use of a 1-element array in struct MR_LD_VF_MAP
with a modern flexible array.
No binary differences are present after this conversion.
Link: https://github.com/KSPP/linux/issues/79 [1]
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20240711155823.work.778-kees@kernel.org
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Kees Cook <kees@kernel.org> says:
Replace all the uses of deprecated 1-element "fake" flexible arrays
with modern C99 flexible arrays.
Link: https://lore.kernel.org/r/20240711155446.work.681-kees@kernel.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Replace the deprecated[1] use of a 1-element array in struct
mpi3_sas_io_unit_page1 with a modern flexible array.
No binary differences are present after this conversion.
Link: https://github.com/KSPP/linux/issues/79 [1]
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20240711155637.3757036-4-kees@kernel.org
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Replace the deprecated[1] use of a 1-element array in struct
mpi3_sas_io_unit_page0 with a modern flexible array.
No binary differences are present after this conversion.
Link: https://github.com/KSPP/linux/issues/79 [1]
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20240711155637.3757036-3-kees@kernel.org
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Replace the deprecated[1] use of a 1-element array in struct
mpi3_event_data_pcie_topology_change_list with a modern flexible array.
Additionally add __counted_by annotation since port_entry is only ever
accessed in loops controlled by num_entries. For example:
for (i = 0; i < event_data->num_entries; i++) {
handle =
le16_to_cpu(event_data->port_entry[i].attached_dev_handle);
No binary differences are present after this conversion.
Link: https://github.com/KSPP/linux/issues/79 [1]
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20240711155637.3757036-2-kees@kernel.org
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Replace the deprecated[1] use of a 1-element array in struct
mpi3_event_data_sas_topology_change_list with a modern flexible array.
Additionally add __counted_by annotation since phy_entry is only ever
accessed in loops controlled by num_entries. For example:
for (i = 0; i < event_data->num_entries; i++) {
...
handle = le16_to_cpu(event_data->phy_entry[i].attached_dev_handle);
No binary differences are present after this conversion.
Link: https://github.com/KSPP/linux/issues/79 [1]
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20240711155637.3757036-1-kees@kernel.org
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
According to the datasheet, the VSC73xx family's maximum internal MDIO bus
speed is 20 MHz. It also allows disabling the preamble.
This commit sets the MDIO clock prescaler to the minimum value and
disables the preamble to speed up MDIO operations.
It doesn't affect the external bus because it's configured in a different
subblock.
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20240731203455.580262-1-paweldembicki@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
commit 3cec055c56 ("rxrpc: Don't hold a ref for connection workqueue")
left behind rxrpc_put_client_conn().
And commit 248f219cb8 ("rxrpc: Rewrite the data and ack handling code")
removed rxrpc_accept_incoming_calls() but left declaration.
Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20240731100815.1277894-1-yuehaibing@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
According to '__reuseport_alloc()', annotate flexible array member
'sock' of 'struct sock_reuseport' with '__counted_by()' and use
convenient 'struct_size()' to simplify the math used in 'kzalloc()'.
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Link: https://patch.msgid.link/20240801142311.42837-1-dmantipov@yandex.ru
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Smatch reports that copying media_name and if_name to name_parts may
overwrite the destination.
.../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16)
.../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16)
This does seem to be the case so guard against this possibility by using
strscpy() and failing if truncation occurs.
Introduced by commit b97bf3fd8f ("[TIPC] Initial merge")
Compile tested only.
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20240801-tipic-overrun-v2-1-c5b869d1f074@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When hv_synic_disable_regs was introduced, it received the description
of hv_synic_cleanup. Fix that.
Fixes: dba61cda30 ("Drivers: hv: vmbus: Break out synic enable and disable operations")
Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
Reviewed-by: Michael Kelley <mhkelley@outlook.com>
Link: https://lore.kernel.org/r/20240801212235.352220-1-romank@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <20240801212235.352220-1-romank@linux.microsoft.com>
In many modern Linux distros, running `lsvmbus` returns the error:
```
/usr/bin/env: 'python': No such file or directory
```
because 'python' doesn't point anywhere.
Now that python2 has reached EOL as of January 1, 2020 and is no longer
maintained[1], these distros have python3 instead.
Also, the script isn't executable by default because the permissions are
set to mode 644.
Fix this by updating the shebang in the `lsvmbus` to use python3 instead
of python. Also fix the permissions to be 755 so that is executable by
default, which matches other similar scripts in `tools/hv`.
The script is also tested and verified that is compatible with
python3.
[1] https://www.python.org/doc/sunset-python-2/
Signed-off-by: Anthony Nandaa <profnandaa@gmail.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/20240702102250.13935-1-profnandaa@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <20240702102250.13935-1-profnandaa@gmail.com>
Use of_property_present() to test for property presence rather than
of_(find|get)_property(). This is part of a larger effort to remove
callers of of_find_property() and similar functions.
of_(find|get)_property() leak the DT struct property and data pointers
which is a problem for dynamically allocated nodes which may be freed.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20240731191312.1710417-4-robh@kernel.org
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> # clk-mstp.c
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Replace of_get_property() with the type specific
of_property_count_u32_elems() to get the property length.
This is part of a larger effort to remove callers of of_get_property()
and similar functions. of_get_property() leaks the DT property data
pointer which is a problem for dynamically allocated nodes which may
be freed.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20240731201407.1838385-7-robh@kernel.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
GVE driver wrongly relies on netif_carrier_ok() to check the
interface administrative state when resources are being
allocated/deallocated for queue(s). netif_carrier_ok() needs
to be replaced with netif_running() for all such cases.
Administrative state is the result of "ip link set dev <dev>
up/down". It reflects whether the administrator wants to use
the device for traffic and the corresponding resources have
been allocated.
Fixes: 5f08cd3d64 ("gve: Alloc before freeing when adjusting queues")
Signed-off-by: Praveen Kaligineedi <pkaligineedi@google.com>
Reviewed-by: Shailend Chand <shailend@google.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20240801205619.987396-1-pkaligineedi@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A Linux guest on Hyper-V gets the TSC frequency from a synthetic MSR, if
available. In this case, set X86_FEATURE_TSC_KNOWN_FREQ so that Linux
doesn't unnecessarily do refined TSC calibration when setting up the TSC
clocksource.
With this change, a message such as this is no longer output during boot
when the TSC is used as the clocksource:
[ 1.115141] tsc: Refined TSC clocksource calibration: 2918.408 MHz
Furthermore, the guest and host will have exactly the same view of the
TSC frequency, which is important for features such as the TSC deadline
timer that are emulated by the Hyper-V host.
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Roman Kisel <romank@linux.microsoft.com>
Link: https://lore.kernel.org/r/20240606025559.1631-1-mhklinux@outlook.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <20240606025559.1631-1-mhklinux@outlook.com>
Nick Child says:
====================
ibmveth RR performance
This patchset aims to increase the ibmveth drivers small packet
request response rate.
These 2 patches address:
1. NAPI rescheduling technique
2. Driver-side processing of small packets
Testing over several netperf tcp_rr connections, we saw a
30% increase in transactions per second. No regressions
were observed in other workloads.
====================
Link: https://patch.msgid.link/20240801211215.128101-1-nnac123@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When the length of a packet is under the rx_copybreak threshold, the
buffer is copied into a new skb and sent up the stack. This allows the
dma mapped memory to be recycled back to FW.
Previously, the reuse of the DMA space was handled immediately.
This means that further packet processing has to wait until
h_add_logical_lan finishes for this packet.
Therefore, when reusing a packet, offload the hcall to the replenish
function. As a result, much of the shared logic between the recycle and
replenish functions can be removed.
This change increases TCP_RR packet rate by another 15% (370k to 430k
txns). We can see the ftrace data supports this:
PREV: ibmveth_poll = 8078553.0 us / 190999.0 hits = AVG 42.3 us
NEW: ibmveth_poll = 7632787.0 us / 224060.0 hits = AVG 34.07 us
Signed-off-by: Nick Child <nnac123@linux.ibm.com>
Reviewed-by: Shannon Nelson <shannon.nelson@amd.com>
Link: https://patch.msgid.link/20240801211215.128101-3-nnac123@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When the ibmveth driver processes less than the budget, it must call
napi_complete_done() to release the instance. This function will
return false if the driver should avoid rearming interrupts.
Previously, the driver was ignoring the return code of
napi_complete_done(). As a result, there were unnecessary calls to
enable the veth irq.
Therefore, use the return code napi_complete_done() to determine if
irq rearm is necessary.
Additionally, in the event that new data is received immediately after
rearming interrupts, rather than just rescheduling napi, also jump
back to the poll processing loop since we are already in the poll
function (and know that we did not expense all of budget).
This slight tweak results in a 15% increase in TCP_RR transaction rate
(320k to 370k txns). We can see the ftrace data supports this:
PREV: ibmveth_poll = 8818014.0 us / 182802.0 hits = AVG 48.24
NEW: ibmveth_poll = 8082398.0 us / 191413.0 hits = AVG 42.22
Signed-off-by: Nick Child <nnac123@linux.ibm.com>
Reviewed-by: Shannon Nelson <shannon.nelson@amd.com>
Link: https://patch.msgid.link/20240801211215.128101-2-nnac123@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
