* RE: [PATCH v2] mshv: Fix interrupt state corruption in hv_do_map_pfns error path
From: Michael Kelley @ 2026-04-28 0:20 UTC (permalink / raw)
To: Stanislav Kinsburskii, kys@microsoft.com, haiyangz@microsoft.com,
wei.liu@kernel.org, decui@microsoft.com, longli@microsoft.com
Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <177730104962.21733.4130809041576931551.stgit@skinsburskii-cloud-desktop.internal.cloudapp.net>
From: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com> Sent: Monday, April 27, 2026 7:44 AM
>
> Restore interrupt state before breaking out of the loop on error.
>
> The irq_flags are saved before entering the loop, but the early exit
> path on error fails to restore them. This leaves interrupts in an
> inconsistent state and can lead to lockdep warnings or other
> interrupt-related issues.
>
> Fixes: 621191d709b14 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs")
> Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
> ---
> drivers/hv/mshv_root_hv_call.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hv/mshv_root_hv_call.c b/drivers/hv/mshv_root_hv_call.c
> index ab210a7fcb8c3..61291ec6f3468 100644
> --- a/drivers/hv/mshv_root_hv_call.c
> +++ b/drivers/hv/mshv_root_hv_call.c
> @@ -229,8 +229,10 @@ static int hv_do_map_gpa_hcall(u64 partition_id, u64 gfn, u64 page_struct_count,
> } else {
> pfnlist[i] = mmio_spa + done + i;
> }
> - if (ret)
> + if (ret) {
> + local_irq_restore(irq_flags);
> break;
> + }
>
This looks good for fixing the immediate bug.
But I'd note that this error path occurs solely based on the
if (index >= page_struct_count) test in the preceding 'for' loop. That test is a
"can't happen" sanity test that never triggers if hv_do_map_gpa_hcall()
is coded correctly. At the beginning of the function there are validations of
the input arguments, which is reasonable. But this sanity test isn't based
on the input arguments, and it adds non-trivial complexity to the code
because of the nested loops and the need to figure out where the two
"break" statements go. I'd argue for dropping the sanity test entirely,
along with this test of 'ret' and the need to restore the interrupt state.
Michael
^ permalink raw reply
* Re: [PATCH V1 08/13] PCI: hv: rename hv_compose_msi_msg to hv_vmbus_compose_msi_msg
From: Mukesh R @ 2026-04-28 2:22 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: hpa, robin.murphy, robh, wei.liu, mhklinux, muislam, namjain,
magnuskulke, anbelski, linux-kernel, linux-hyperv, iommu,
linux-pci, linux-arch, kys, haiyangz, decui, longli, tglx, mingo,
bp, dave.hansen, x86, joro, will, lpieralisi, kwilczynski,
bhelgaas, arnd
In-Reply-To: <20260427163139.GA157548@bhelgaas>
On 4/27/26 09:31, Bjorn Helgaas wrote:
> On Tue, Apr 21, 2026 at 07:32:34PM -0700, Mukesh R wrote:
>> Main change here is to rename hv_compose_msi_msg to
>> hv_vmbus_compose_msi_msg as we introduce hv_compose_msi_msg in upcoming
>> patches that builds MSI messages for both VMBus and non-VMBus cases. VMBus
>> is not used on baremetal root partition for example. While at it, replace
>> spaces with tabs and fix some formatting involving excessive line wraps.
>
> Would be better to do the whitespace changes in their own patch,
> although several of them should just be dropped (see below).
>
> Capitalize subject ("PCI: hv: Rename ...").
>
> Add "()" after function names in subject and commit log.
Ok, will do in next version.
>> +++ b/drivers/pci/controller/pci-hyperv.c
>> @@ -30,7 +30,7 @@
>> * function's configuration space is zero.
>> *
>> * The rest of this driver mostly maps PCI concepts onto underlying Hyper-V
>> - * facilities. For instance, the configuration space of a function exposed
>> + * facilities. For instance, the configuration space of a function exposed
>
> Oops, this hunk made it worse. Definitely don't want a tab there.
>
>> @@ -1954,7 +1955,7 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
>> return;
>> }
>> /*
>> - * The vector we select here is a dummy value. The correct
>> + * The vector we select here is a dummy value. The correct
>
> Another tab that should be a space. Actually, you should just drop
> this hunk; the rest of the comment has two spaces after periods, so
> this should too.
well, most of our files does global replace 8 spaces with tabs, so
everywhere comments are well indented. Since, checkpatch doesn't complain
about tabs on comment lines, may I assue it is not a strict requirement
and more a nit or personal preference?
Thanks,
-Mukesh
>> @@ -2046,7 +2047,7 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
>>
>> /*
>> * Make sure that the ring buffer data structure doesn't get
>> - * freed while we dereference the ring buffer pointer. Test
>> + * freed while we dereference the ring buffer pointer. Test
>
> Same here. This makes it worse.
>
>> @@ -2226,7 +2227,7 @@ static int hv_pcie_init_irq_domain(struct hv_pcibus_device *hbus)
>> /**
>> * get_bar_size() - Get the address space consumed by a BAR
>> * @bar_val: Value that a BAR returned after -1 was written
>> - * to it.
>> + * to it.
>
> Just put "to it" on the preceding line. There's plenty of space
> there.
>
>> @@ -2580,7 +2581,7 @@ static void q_resource_requirements(void *context, struct pci_response *resp,
>> * new_pcichild_device() - Create a new child device
>> * @hbus: The internal struct tracking this root PCI bus.
>> * @desc: The information supplied so far from the host
>> - * about the device.
>> + * about the device.
>
> Ditto. If you want to change this, put "about the device" on the
> preceding line.
>
>> @@ -3422,7 +3423,7 @@ static int hv_allocate_config_window(struct hv_pcibus_device *hbus)
>> * vmbus_allocate_mmio() gets used for allocating both device endpoint
>> * resource claims (those which cannot be overlapped) and the ranges
>> * which are valid for the children of this bus, which are intended
>> - * to be overlapped by those children. Set the flag on this claim
>> + * to be overlapped by those children. Set the flag on this claim
>
> Another hunk that should be dropped.
^ permalink raw reply
* Re: [PATCH V1 13/13] mshv: pin all ram mem regions if partition has device passthru
From: Mukesh R @ 2026-04-28 2:23 UTC (permalink / raw)
To: hpa, robin.murphy, robh, wei.liu, mhklinux, muislam, namjain,
magnuskulke, anbelski, linux-kernel, linux-hyperv, iommu,
linux-pci, linux-arch
Cc: kys, haiyangz, decui, longli, tglx, mingo, bp, dave.hansen, x86,
joro, will, lpieralisi, kwilczynski, bhelgaas, arnd
In-Reply-To: <20260422023239.1171963-14-mrathor@linux.microsoft.com>
Please ignore this patch, something went wrong during merge/rebase.
The setting of pt_regions_pinned should be in a different function.
Thanks,
-Mukesh
On 4/21/26 19:32, Mukesh R wrote:
> Given the sporadic errors, mostly from high end devices, when regions are
> not pinned and a PCI device is passthru'd to a VM, for now, force all
> regions for the VM to be pinned. Even tho VFIO may pin them, the regions
> would still be marked movable, so do it upfront in mshv.
>
> Signed-off-by: Mukesh R <mrathor@linux.microsoft.com>
> ---
> drivers/hv/mshv_root.h | 6 ++++++
> drivers/hv/mshv_root_main.c | 5 ++++-
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hv/mshv_root.h b/drivers/hv/mshv_root.h
> index b9880d0bdc4d..32260df84f86 100644
> --- a/drivers/hv/mshv_root.h
> +++ b/drivers/hv/mshv_root.h
> @@ -141,6 +141,7 @@ struct mshv_partition {
> pid_t pt_vmm_tgid;
> bool import_completed;
> bool pt_initialized;
> + bool pt_regions_pinned;
> #if IS_ENABLED(CONFIG_DEBUG_FS)
> struct dentry *pt_stats_dentry;
> struct dentry *pt_vp_dentry;
> @@ -277,6 +278,11 @@ static inline bool mshv_partition_encrypted(struct mshv_partition *partition)
> return partition->isolation_type == HV_PARTITION_ISOLATION_TYPE_SNP;
> }
>
> +static inline bool mshv_pt_regions_pinned(struct mshv_partition *pt)
> +{
> + return pt->pt_regions_pinned || mshv_partition_encrypted(pt);
> +}
> +
> struct mshv_partition *mshv_partition_get(struct mshv_partition *partition);
> void mshv_partition_put(struct mshv_partition *partition);
> struct mshv_partition *mshv_partition_find(u64 partition_id) __must_hold(RCU);
> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> index a7864463961b..251cf88a2b0b 100644
> --- a/drivers/hv/mshv_root_main.c
> +++ b/drivers/hv/mshv_root_main.c
> @@ -1333,7 +1333,7 @@ static int mshv_partition_create_region(struct mshv_partition *partition,
>
> if (is_mmio)
> rg->mreg_type = MSHV_REGION_TYPE_MMIO;
> - else if (mshv_partition_encrypted(partition) ||
> + else if (mshv_pt_regions_pinned(partition) ||
> !mshv_region_movable_init(rg))
> rg->mreg_type = MSHV_REGION_TYPE_MEM_PINNED;
> else
> @@ -1406,6 +1406,9 @@ static int mshv_prepare_pinned_region(struct mshv_mem_region *region)
> goto err_out;
> }
>
> + /* For now, all regions must be pinned if there is device passthru. */
> + partition->pt_regions_pinned = true;
> +
> return 0;
>
> invalidate_region:
^ permalink raw reply
* [PATCH AUTOSEL 7.0-5.10] scsi: storvsc: Handle PERSISTENT_RESERVE_IN truncation for Hyper-V vFC
From: Sasha Levin @ 2026-04-28 10:40 UTC (permalink / raw)
To: patches, stable
Cc: Li Tian, Long Li, Laurence Oberman, Martin K. Petersen,
Sasha Levin, kys, haiyangz, wei.liu, decui, jejb, linux-hyperv,
linux-scsi, linux-kernel
In-Reply-To: <20260428104133.2858589-1-sashal@kernel.org>
From: Li Tian <litian@redhat.com>
[ Upstream commit 9cf351b289fb2be22491fa3964f99126db67aa08 ]
The storvsc driver has become stricter in handling SRB status codes
returned by the Hyper-V host. When using Virtual Fibre Channel (vFC)
passthrough, the host may return SRB_STATUS_DATA_OVERRUN for
PERSISTENT_RESERVE_IN commands if the allocation length in the CDB does
not match the host's expected response size.
Currently, this status is treated as a fatal error, propagating
Host_status=0x07 [DID_ERROR] to the SCSI mid-layer. This causes
userspace storage utilities (such as sg_persist) to fail with transport
errors, even when the host has actually returned the requested
reservation data in the buffer.
Refactor the existing command-specific workarounds into a new helper
function, storvsc_host_mishandles_cmd(), and add PERSISTENT_RESERVE_IN
to the list of commands where SRB status errors should be suppressed for
vFC devices. This ensures that the SCSI mid-layer processes the returned
data buffer instead of terminating the command.
Signed-off-by: Li Tian <litian@redhat.com>
Reviewed-by: Long Li <longli@microsoft.com>
Reviewed-by: Laurence Oberman <loberman@redhat.com>
Link: https://patch.msgid.link/20260406015344.12566-1-litian@redhat.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have enough information. Let me synthesize the full analysis.
---
## Phase 1: Commit Message Forensics
**Step 1.1 — Subject line parse**
Record: Subsystem `scsi: storvsc`, verb "Handle" (bug-fix indicator),
summary: treat SRB_STATUS_DATA_OVERRUN for PERSISTENT_RESERVE_IN on
Hyper-V vFC as success instead of DID_ERROR.
**Step 1.2 — Tags**
Record:
- Signed-off-by: Li Tian (Red Hat, author)
- Reviewed-by: Long Li (Microsoft, storvsc maintainer/co-maintainer)
- Reviewed-by: Laurence Oberman (Red Hat, storage expert)
- Link: patch.msgid.link (lore)
- Signed-off-by: Martin K. Petersen (SCSI maintainer)
- No Fixes:, no Cc: stable (expected for manual review candidates)
**Step 1.3 — Body analysis**
Record: Bug is concrete and user-visible. When the storvsc driver became
stricter (SRB_STATUS_DATA_OVERRUN treated as error), Hyper-V vFC started
failing PERSISTENT_RESERVE_IN with `Host_status=0x07 [DID_ERROR]`, which
causes `sg_persist` and other SCSI-3 PR utilities to fail with transport
errors even though the reservation data was correctly returned in the
buffer. Root cause: the host echoes SRB_STATUS_DATA_OVERRUN when the
CDB's allocation length does not match the host's expected response
size.
**Step 1.4 — Hidden bug-fix detection**
Record: "Handle ... truncation" = explicit bug fix; the refactor is
incidental.
---
## Phase 2: Diff Analysis
**Step 2.1 — Inventory**
Record: Single file `drivers/scsi/storvsc_drv.c`, +21/-11, scope: one
new static helper (`storvsc_host_mishandles_cmd`) and a rewrite of one
`if` expression in `storvsc_on_io_completion`.
**Step 2.2 — Code flow change**
Record:
- BEFORE: `if ((cdb[0]==INQUIRY) || (cdb[0]==MODE_SENSE) ||
(cdb[0]==MODE_SENSE_10) || (cdb[0]==MAINTENANCE_IN &&
hv_dev_is_fc(device)))` → mask status to success
- AFTER: `if (storvsc_host_mishandles_cmd(cdb[0], device))` → same mask;
helper adds `PERSISTENT_RESERVE_IN` under the FC-gated arm
**Step 2.3 — Bug mechanism**
Record: Hardware-workaround / status-filtering bug. Adds
PERSISTENT_RESERVE_IN to the same whitelist used for MAINTENANCE_IN —
i.e., commands for which Hyper-V vFC returns SRB_STATUS_DATA_OVERRUN
despite the data being correct.
**Step 2.4 — Fix quality**
Record: Obviously correct: the new `switch` is semantically identical to
the old `if` for existing opcodes; it only adds PERSISTENT_RESERVE_IN
under `hv_dev_is_fc(device)`. Minimal, surgical. Refactor into a helper
is cosmetic but slightly expands diff; no functional change for non-vFC
devices or for other opcodes.
---
## Phase 3: Git History Investigation
**Step 3.1 — Blame**
Record: The stricter handling of SRB_STATUS_DATA_OVERRUN was introduced
by commit `812fe6420a6e7` ("scsi: storvsc: Handle additional SRB status
values"), which went into **v6.6-rc1**. Before that, unknown SRB
statuses were simply ignored, so the bug did not manifest.
**Step 3.2 — Fixes: follow-up**
Record: There is no Fixes: tag, but the root-cause commit is clearly
`812fe6420a6e7` (v6.6). That commit IS present in all stable trees from
6.6.y onward, so the bug it introduced is present in all those trees.
**Step 3.3 — File history / related commits**
Record:
- `b1aee7f034615` ("scsi: storvsc: Do not flag MAINTENANCE_IN return of
SRB_STATUS_DATA_OVERRUN as an error", v6.13-rc2, Cathy Avery) —
parallel fix for MAINTENANCE_IN/RTPG. **Confirmed via web search this
was AUTOSEL'd to 6.6.y stable (`[PATCH AUTOSEL 6.6 17/23]` on lkml).**
- `9eacec5d18f98` ("scsi: storvsc: Process unsupported MODE_SENSE_10",
2026) — also had `Cc: stable@kernel.org` and `Fixes:`.
- The current commit is effectively "MAINTENANCE_IN fix, part 2" for a
different opcode.
**Step 3.4 — Author context**
Record: Li Tian (Red Hat) — regular contributor of Hyper-V /
virtualization fixes. Reviewed by Long Li (Microsoft), who is the
storvsc maintainer. Strong review signal.
**Step 3.5 — Dependencies**
Record: Uses `hv_dev_is_fc(device)`, `INQUIRY`, `MODE_SENSE`,
`MODE_SENSE_10`, `MAINTENANCE_IN`, `PERSISTENT_RESERVE_IN`, all of which
exist in every stable tree 6.6+. Patch is self-contained.
---
## Phase 4: Mailing List and External Research
**Step 4.1 — b4 dig**
Record: `b4 dig -c 9cf351b289fb2` matched by patch-id, single series,
only v1, URL
`https://lore.kernel.org/all/20260406015344.12566-1-litian@redhat.com`.
No v2 or further revisions — applied as submitted.
**Step 4.2 — b4 dig -w**
Record: Recipients included linux-scsi, linux-hyperv, Microsoft
maintainers (K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long
Li), James Bottomley, and Martin K. Petersen. The right audience
reviewed it.
**Step 4.3 — Thread contents (saved mbox)**
Record: Thread contains:
- Reviewed-by: Long Li: "Reviewed-by: Long Li <longli@microsoft.com>"
- Reviewed-by: Laurence Oberman: "Looks good, rewrite of how it was done
before but will achieve the same behavior we wanted for the new
addition for PR. Reviewed-by: Laurence Oberman."
- Martin K. Petersen applied to 7.1/scsi-staging and later 7.1/scsi-
queue.
No NAKs, no stable-suitability concerns raised. No explicit `Cc: stable`
nomination, but also no objections.
**Step 4.4 — Series**
Record: Standalone single-patch series, no dependencies.
**Step 4.5 — Stable list history**
Record: Could not access lore.kernel.org/stable (bot protection). Web
search confirms the sibling MAINTENANCE_IN fix `b1aee7f034615` was
selected by AUTOSEL for 6.6.y, validating the pattern for stable
backport.
---
## Phase 5: Code Semantic Analysis
**Step 5.1–5.2 — Callers**
Record: `storvsc_on_io_completion` is called from `storvsc_on_receive`
for `VSTOR_OPERATION_COMPLETE_IO`, which is the primary completion path
for every SCSI command issued through storvsc. Every `sg_persist` or
other userspace PR issuer for a vFC LUN reaches this code.
**Step 5.3 — Callees**
Record: `hv_dev_is_fc()` is a trivial GUID comparison
(`HV_SYNTHFC_GUID`); no side effects.
**Step 5.4 — Reachability**
Record: Yes, trivially reachable from userspace: `/dev/sgN` ioctl →
PERSISTENT_RESERVE_IN CDB → storvsc → this completion path. Used by
`sg_persist`, `multipath`, cluster software.
**Step 5.5 — Similar patterns**
Record: Same pattern already applied for INQUIRY (pre-2014),
MODE_SENSE/MODE_SENSE_10 (`9eacec5d18f98`, Cc: stable), and
MAINTENANCE_IN (`b1aee7f034615`, AUTOSEL to 6.6.y).
---
## Phase 6: Stable Tree Analysis
**Step 6.1 — Bug presence in stable**
Record: Stricter SRB_STATUS_DATA_OVERRUN handling (812fe6420a6e7) is in
v6.6+. Therefore the PERSISTENT_RESERVE_IN regression exists in 6.6.y,
6.12.y, 6.15.y, 6.18.y and current trees.
**Step 6.2 — Backport complications**
Record: On stable trees that already have the MAINTENANCE_IN fix
(`b1aee7f034615`), the diff context matches exactly and should apply
cleanly with minor refactor. On any tree missing the MAINTENANCE_IN fix,
the refactor-into-helper form may need trivial adjustment. Given that
`b1aee7f034615` was AUTOSEL'd to 6.6.y, most 6.6+ stable trees should
have it.
**Step 6.3 — Related fixes already in stable**
Record: `b1aee7f034615` (MAINTENANCE_IN) and `9eacec5d18f98`
(MODE_SENSE_10) are already in stable. This completes the triad for vFC
command-mishandle workarounds.
---
## Phase 7: Subsystem Context
**Step 7.1 — Criticality**
Record: `drivers/scsi/storvsc_drv.c` — Hyper-V synthetic SCSI/FC driver.
IMPORTANT (used by every Linux VM running on Hyper-V/Azure that uses vFC
for storage — enterprise and cloud).
**Step 7.2 — Activity**
Record: Actively maintained; recent commits (MODE_SENSE_10,
MAINTENANCE_IN, queue/channel work). Not a stale subsystem.
---
## Phase 8: Impact and Risk
**Step 8.1 — Affected population**
Record: Linux VMs on Hyper-V/Azure using vFC passthrough with SCSI-3
persistent reservations (HA clusters, shared-storage coordination,
`sg_persist` consumers). Significant enterprise user base; not a niche
driver.
**Step 8.2 — Trigger**
Record: Any userspace call issuing PERSISTENT_RESERVE_IN (service action
READ_KEYS, READ_RESERVATION, REPORT_CAPABILITIES, READ_FULL_STATUS) to a
vFC LUN. Reproduces via `sg_persist -k /dev/sdX`. Unprivileged trigger:
limited by device permissions, but not a kernel-level security issue.
**Step 8.3 — Failure mode severity**
Record: User-visible I/O failure (sg_persist returns transport error,
multipath/cluster software fails to query/modify reservations). Severity
MEDIUM — no crash, no corruption, but broken functionality that blocks
clustering on Hyper-V vFC.
**Step 8.4 — Risk/benefit**
Record:
- Benefit: restores working SCSI-3 PR on Hyper-V vFC for all stable
users on 6.6+.
- Risk: very low — change is gated on opcode == PERSISTENT_RESERVE_IN
AND device is vFC. Non-vFC storvsc devices and non-PR opcodes are
unaffected. The refactor is semantically equivalent for existing
cases.
Ratio: favorable.
---
## Phase 9: Final Synthesis
**Step 9.1 — Evidence**
FOR: real user-visible bug (sg_persist failure), subsystem-maintainer +
independent reviewer sign-off, small single-file diff, follows
established pattern (MAINTENANCE_IN fix was AUTOSEL'd to 6.6.y), bug
present in all 6.6+ stable trees, no dependencies, low regression
surface.
AGAINST: includes a refactor-into-helper along with the fix (minor
cosmetic); missing explicit `Cc: stable` tag (but that's expected for
manually-reviewed candidates and also absent from the already-backported
MAINTENANCE_IN fix).
**Step 9.2 — Stable rules checklist**
1. Obviously correct & tested? YES (reviewed by MS + RH; switch is
semantically equivalent for existing opcodes).
2. Fixes a real bug affecting users? YES (sg_persist on vFC).
3. Important issue? YES — breaks clustering/PR on a widely-used
virtualization platform (MEDIUM-HIGH severity).
4. Small & contained? YES (+21/-11, one file).
5. No new features/APIs? YES (workaround only).
6. Applies to stable? YES (clean on 6.13+; likely clean on 6.6.y–6.12.y
which already have the sibling MAINTENANCE_IN fix).
**Step 9.3 — Exception category**
Record: Falls under "hardware workaround / quirk" exception — the host-
side mishandling is effectively a device bug the driver compensates for.
**Step 9.4 — Decision**
YES.
---
### Verification
- [Phase 1] Parsed tags via Read of commit message: found 2 Reviewed-by,
Link:, Signed-off-by chain. No Fixes/Cc:stable.
- [Phase 2] `git show 9cf351b289fb2`: confirmed +21/-11, single file,
refactor + PERSISTENT_RESERVE_IN addition gated on
`hv_dev_is_fc(device)`.
- [Phase 3] `git log --oneline --grep="MAINTENANCE_IN" --
drivers/scsi/storvsc_drv.c`: found sibling fix `b1aee7f034615`.
- [Phase 3] `git show 812fe6420a6e`: confirmed this is the commit that
introduced the stricter handling. `git describe --contains
812fe6420a6e` → `v6.6-rc1~11^2~9^2` (v6.6).
- [Phase 3] `git describe --contains b1aee7f034615` → v6.13-rc2~7^2~1
(MAINTENANCE_IN fix landed in v6.13).
- [Phase 3] `git show 9eacec5d18f98`: confirmed MODE_SENSE_10 handling
fix explicitly had `Cc: stable@kernel.org` and `Fixes:` tag (similar
hardware-mishandling pattern).
- [Phase 4] `b4 dig -c 9cf351b289fb2`: matched by patch-id, single
version v1, lore URL obtained.
- [Phase 4] `b4 dig -c 9cf351b289fb2 -a`: only v1 exists (no v2/v3;
applied as submitted).
- [Phase 4] `b4 dig -c 9cf351b289fb2 -w`: correct recipients (Microsoft
storvsc maintainers + linux-scsi + linux-hyperv + MKP).
- [Phase 4] Saved thread to /tmp/thread.mbox and read it: found Long
Li's Reviewed-by, Laurence Oberman's Reviewed-by ("Looks good, rewrite
of how it was done before..."), and Martin K. Petersen's "Applied to
7.1/scsi-queue". No NAKs, no concerns.
- [Phase 4] WebSearch confirmed `b1aee7f034615` was listed as "[PATCH
AUTOSEL 6.6 17/23]" on lkml, validating that the AUTOSEL process
already backported the sibling fix.
- [Phase 5] Grep for `storvsc_on_io_completion`: confirmed it is called
from `storvsc_on_receive` on `VSTOR_OPERATION_COMPLETE_IO`, i.e.,
every SCSI completion path.
- [Phase 5] Read `hv_dev_is_fc` (line 1928): trivial GUID match against
`HV_SYNTHFC_GUID` — zero side effects.
- [Phase 6] v6.6 contains 812fe6420a6e (bug root cause is present in
6.6.y, 6.12.y, 6.15.y, 6.18.y).
- [Phase 8] Failure mode: sg_persist returns DID_ERROR even when host
returned data; breaks SCSI-3 PR on vFC — MEDIUM severity, broad impact
on enterprise Hyper-V users.
- UNVERIFIED: Could not fetch lore.kernel.org/stable directly (Anubis
bot protection), so I could not confirm whether this specific commit
is already under stable discussion. This does not change the YES
decision; it is based on technical merit.
- UNVERIFIED: Did not run an actual `git am` against linux-stable
branches to confirm clean apply, but the code context (lines 1131–1180
in storvsc_drv.c) matches the upstream base `ae1abab97835` (index in
diff) and all referenced symbols (`INQUIRY`, `MODE_SENSE_10`,
`MAINTENANCE_IN`, `PERSISTENT_RESERVE_IN`, `hv_dev_is_fc`) exist in
6.13+ trees with the MAINTENANCE_IN fix already present.
This is a small, well-reviewed hardware-workaround fix for a real user-
visible regression (sg_persist/SCSI-3 PR broken on Hyper-V vFC since
v6.6), following an established pattern whose sibling was already
AUTOSEL'd to stable. Benefit clearly outweighs risk.
**YES**
drivers/scsi/storvsc_drv.c | 32 +++++++++++++++++++++-----------
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index ae1abab97835b..6977ca8a06582 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1131,6 +1131,26 @@ static void storvsc_command_completion(struct storvsc_cmd_request *cmd_request,
kfree(payload);
}
+/*
+ * The current SCSI handling on the host side does not correctly handle:
+ * INQUIRY with page code 0x80, MODE_SENSE / MODE_SENSE_10 with cmd[2] == 0x1c,
+ * and (for FC) MAINTENANCE_IN / PERSISTENT_RESERVE_IN passthrough.
+ */
+static bool storvsc_host_mishandles_cmd(u8 opcode, struct hv_device *device)
+{
+ switch (opcode) {
+ case INQUIRY:
+ case MODE_SENSE:
+ case MODE_SENSE_10:
+ return true;
+ case MAINTENANCE_IN:
+ case PERSISTENT_RESERVE_IN:
+ return hv_dev_is_fc(device);
+ default:
+ return false;
+ }
+}
+
static void storvsc_on_io_completion(struct storvsc_device *stor_device,
struct vstor_packet *vstor_packet,
struct storvsc_cmd_request *request)
@@ -1141,22 +1161,12 @@ static void storvsc_on_io_completion(struct storvsc_device *stor_device,
stor_pkt = &request->vstor_packet;
/*
- * The current SCSI handling on the host side does
- * not correctly handle:
- * INQUIRY command with page code parameter set to 0x80
- * MODE_SENSE and MODE_SENSE_10 command with cmd[2] == 0x1c
- * MAINTENANCE_IN is not supported by HyperV FC passthrough
- *
* Setup srb and scsi status so this won't be fatal.
* We do this so we can distinguish truly fatal failues
* (srb status == 0x4) and off-line the device in that case.
*/
- if ((stor_pkt->vm_srb.cdb[0] == INQUIRY) ||
- (stor_pkt->vm_srb.cdb[0] == MODE_SENSE) ||
- (stor_pkt->vm_srb.cdb[0] == MODE_SENSE_10) ||
- (stor_pkt->vm_srb.cdb[0] == MAINTENANCE_IN &&
- hv_dev_is_fc(device))) {
+ if (storvsc_host_mishandles_cmd(stor_pkt->vm_srb.cdb[0], device)) {
vstor_packet->vm_srb.scsi_status = 0;
vstor_packet->vm_srb.srb_status = SRB_STATUS_SUCCESS;
}
--
2.53.0
^ permalink raw reply related
* [PATCH] hv_sock: fix ARM64 support
From: Hamza Mahfooz @ 2026-04-28 11:05 UTC (permalink / raw)
To: netdev
Cc: K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Stefano Garzarella, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Michael Kelley, Himadri Pandya,
linux-hyperv, virtualization, linux-kernel, Hamza Mahfooz, stable
VMBUS ring buffers must be page aligned. Therefore, the current value of
24K presents a challenge on ARM64 kernels (with 64K pages). So, use
VMBUS_RING_SIZE() to ensure they are always aligned and large enough to
hold all of the relevant data.
Cc: stable@kernel.vger.org
Fixes: 77ffe33363c0 ("hv_sock: use HV_HYP_PAGE_SIZE for Hyper-V communication")
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
---
net/vmw_vsock/hyperv_transport.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index 069386a74557..40f09b23efa3 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -375,10 +375,10 @@ static void hvs_open_connection(struct vmbus_channel *chan)
} else {
sndbuf = max_t(int, sk->sk_sndbuf, RINGBUFFER_HVS_SND_SIZE);
sndbuf = min_t(int, sndbuf, RINGBUFFER_HVS_MAX_SIZE);
- sndbuf = ALIGN(sndbuf, HV_HYP_PAGE_SIZE);
+ sndbuf = VMBUS_RING_SIZE(sndbuf);
rcvbuf = max_t(int, sk->sk_rcvbuf, RINGBUFFER_HVS_RCV_SIZE);
rcvbuf = min_t(int, rcvbuf, RINGBUFFER_HVS_MAX_SIZE);
- rcvbuf = ALIGN(rcvbuf, HV_HYP_PAGE_SIZE);
+ rcvbuf = VMBUS_RING_SIZE(rcvbuf);
}
chan->max_pkt_size = HVS_MAX_PKT_SIZE;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] hv_sock: fix ARM64 support
From: Stefano Garzarella @ 2026-04-28 12:15 UTC (permalink / raw)
To: Hamza Mahfooz
Cc: netdev, K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui,
Long Li, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Michael Kelley, Himadri Pandya,
linux-hyperv, virtualization, linux-kernel, stable
In-Reply-To: <20260428110530.1717647-1-hamzamahfooz@linux.microsoft.com>
On Tue, Apr 28, 2026 at 07:05:30AM -0400, Hamza Mahfooz wrote:
>VMBUS ring buffers must be page aligned. Therefore, the current value of
>24K presents a challenge on ARM64 kernels (with 64K pages). So, use
>VMBUS_RING_SIZE() to ensure they are always aligned and large enough to
>hold all of the relevant data.
>
>Cc: stable@kernel.vger.org
mmm, this is the first time I've seen this address used for stable. Even
after searching in the log, I don't see anyone else who's used it.
Where did you get it from?
From Documentation/process/stable-kernel-rules.rst :
To have a patch you submit for mainline inclusion later automatically
picked up for stable trees, add this tag in the sign-off area::
Cc: stable@vger.kernel.org
The patch LGTM.
Thanks,
Stefano
>Fixes: 77ffe33363c0 ("hv_sock: use HV_HYP_PAGE_SIZE for Hyper-V communication")
>Tested-by: Dexuan Cui <decui@microsoft.com>
>Reviewed-by: Dexuan Cui <decui@microsoft.com>
>Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
>---
> net/vmw_vsock/hyperv_transport.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
>index 069386a74557..40f09b23efa3 100644
>--- a/net/vmw_vsock/hyperv_transport.c
>+++ b/net/vmw_vsock/hyperv_transport.c
>@@ -375,10 +375,10 @@ static void hvs_open_connection(struct vmbus_channel *chan)
> } else {
> sndbuf = max_t(int, sk->sk_sndbuf, RINGBUFFER_HVS_SND_SIZE);
> sndbuf = min_t(int, sndbuf, RINGBUFFER_HVS_MAX_SIZE);
>- sndbuf = ALIGN(sndbuf, HV_HYP_PAGE_SIZE);
>+ sndbuf = VMBUS_RING_SIZE(sndbuf);
> rcvbuf = max_t(int, sk->sk_rcvbuf, RINGBUFFER_HVS_RCV_SIZE);
> rcvbuf = min_t(int, rcvbuf, RINGBUFFER_HVS_MAX_SIZE);
>- rcvbuf = ALIGN(rcvbuf, HV_HYP_PAGE_SIZE);
>+ rcvbuf = VMBUS_RING_SIZE(rcvbuf);
> }
>
> chan->max_pkt_size = HVS_MAX_PKT_SIZE;
>--
>2.54.0
>
^ permalink raw reply
* Re: [PATCH] hv_sock: fix ARM64 support
From: Hamza Mahfooz @ 2026-04-28 12:35 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui,
Long Li, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Michael Kelley, Himadri Pandya,
linux-hyperv, virtualization, linux-kernel, stable
In-Reply-To: <afCjpGa4Xm4hIPj6@sgarzare-redhat>
On Tue, Apr 28, 2026 at 02:15:26PM +0200, Stefano Garzarella wrote:
> On Tue, Apr 28, 2026 at 07:05:30AM -0400, Hamza Mahfooz wrote:
> > VMBUS ring buffers must be page aligned. Therefore, the current value of
> > 24K presents a challenge on ARM64 kernels (with 64K pages). So, use
> > VMBUS_RING_SIZE() to ensure they are always aligned and large enough to
> > hold all of the relevant data.
> >
> > Cc: stable@kernel.vger.org
>
> mmm, this is the first time I've seen this address used for stable. Even
> after searching in the log, I don't see anyone else who's used it.
> Where did you get it from?
>
> From Documentation/process/stable-kernel-rules.rst :
>
> To have a patch you submit for mainline inclusion later automatically
> picked up for stable trees, add this tag in the sign-off area::
>
> Cc: stable@vger.kernel.org
Ya, that is the address I intended to Cc, not sure how I ended up
mangling it though.
>
>
> The patch LGTM.
>
> Thanks,
> Stefano
>
> > Fixes: 77ffe33363c0 ("hv_sock: use HV_HYP_PAGE_SIZE for Hyper-V communication")
> > Tested-by: Dexuan Cui <decui@microsoft.com>
> > Reviewed-by: Dexuan Cui <decui@microsoft.com>
> > Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
> > ---
> > net/vmw_vsock/hyperv_transport.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
> > index 069386a74557..40f09b23efa3 100644
> > --- a/net/vmw_vsock/hyperv_transport.c
> > +++ b/net/vmw_vsock/hyperv_transport.c
> > @@ -375,10 +375,10 @@ static void hvs_open_connection(struct vmbus_channel *chan)
> > } else {
> > sndbuf = max_t(int, sk->sk_sndbuf, RINGBUFFER_HVS_SND_SIZE);
> > sndbuf = min_t(int, sndbuf, RINGBUFFER_HVS_MAX_SIZE);
> > - sndbuf = ALIGN(sndbuf, HV_HYP_PAGE_SIZE);
> > + sndbuf = VMBUS_RING_SIZE(sndbuf);
> > rcvbuf = max_t(int, sk->sk_rcvbuf, RINGBUFFER_HVS_RCV_SIZE);
> > rcvbuf = min_t(int, rcvbuf, RINGBUFFER_HVS_MAX_SIZE);
> > - rcvbuf = ALIGN(rcvbuf, HV_HYP_PAGE_SIZE);
> > + rcvbuf = VMBUS_RING_SIZE(rcvbuf);
> > }
> >
> > chan->max_pkt_size = HVS_MAX_PKT_SIZE;
> > --
> > 2.54.0
> >
>
^ permalink raw reply
* [PATCH] hv_sock: fix ARM64 support
From: Hamza Mahfooz @ 2026-04-28 12:53 UTC (permalink / raw)
To: netdev
Cc: K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Stefano Garzarella, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Michael Kelley, Himadri Pandya,
linux-hyperv, virtualization, linux-kernel
VMBUS ring buffers must be page aligned. Therefore, the current value of
24K presents a challenge on ARM64 kernels (with 64K pages). So, use
VMBUS_RING_SIZE() to ensure they are always aligned and large enough to
hold all of the relevant data.
Cc: stable@vger.kernel.org
Fixes: 77ffe33363c0 ("hv_sock: use HV_HYP_PAGE_SIZE for Hyper-V communication")
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
---
net/vmw_vsock/hyperv_transport.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index 069386a74557..40f09b23efa3 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -375,10 +375,10 @@ static void hvs_open_connection(struct vmbus_channel *chan)
} else {
sndbuf = max_t(int, sk->sk_sndbuf, RINGBUFFER_HVS_SND_SIZE);
sndbuf = min_t(int, sndbuf, RINGBUFFER_HVS_MAX_SIZE);
- sndbuf = ALIGN(sndbuf, HV_HYP_PAGE_SIZE);
+ sndbuf = VMBUS_RING_SIZE(sndbuf);
rcvbuf = max_t(int, sk->sk_rcvbuf, RINGBUFFER_HVS_RCV_SIZE);
rcvbuf = min_t(int, rcvbuf, RINGBUFFER_HVS_MAX_SIZE);
- rcvbuf = ALIGN(rcvbuf, HV_HYP_PAGE_SIZE);
+ rcvbuf = VMBUS_RING_SIZE(rcvbuf);
}
chan->max_pkt_size = HVS_MAX_PKT_SIZE;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] hv_sock: fix ARM64 support
From: Stefano Garzarella @ 2026-04-28 13:12 UTC (permalink / raw)
To: Hamza Mahfooz
Cc: netdev, K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui,
Long Li, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Michael Kelley, Himadri Pandya,
linux-hyperv, virtualization, linux-kernel
In-Reply-To: <20260428125339.13963-1-hamzamahfooz@linux.microsoft.com>
No version number in the subject?
Please next time follow
https://docs.kernel.org/process/submitting-patches.html#subject-line
Common tags might include a version descriptor if the multiple
versions of the patch have been sent out in response to comments
(i.e., “v1, v2, v3”), or “RFC” to indicate a request for comments.
On Tue, Apr 28, 2026 at 08:53:39AM -0400, Hamza Mahfooz wrote:
>VMBUS ring buffers must be page aligned. Therefore, the current value of
>24K presents a challenge on ARM64 kernels (with 64K pages). So, use
>VMBUS_RING_SIZE() to ensure they are always aligned and large enough to
>hold all of the relevant data.
>
>Cc: stable@vger.kernel.org
>Fixes: 77ffe33363c0 ("hv_sock: use HV_HYP_PAGE_SIZE for Hyper-V communication")
>Tested-by: Dexuan Cui <decui@microsoft.com>
>Reviewed-by: Dexuan Cui <decui@microsoft.com>
>Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
>---
> net/vmw_vsock/hyperv_transport.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Stefano Garzarella <sgarzare@redhat.com>
>
>diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
>index 069386a74557..40f09b23efa3 100644
>--- a/net/vmw_vsock/hyperv_transport.c
>+++ b/net/vmw_vsock/hyperv_transport.c
>@@ -375,10 +375,10 @@ static void hvs_open_connection(struct vmbus_channel *chan)
> } else {
> sndbuf = max_t(int, sk->sk_sndbuf, RINGBUFFER_HVS_SND_SIZE);
> sndbuf = min_t(int, sndbuf, RINGBUFFER_HVS_MAX_SIZE);
>- sndbuf = ALIGN(sndbuf, HV_HYP_PAGE_SIZE);
>+ sndbuf = VMBUS_RING_SIZE(sndbuf);
> rcvbuf = max_t(int, sk->sk_rcvbuf, RINGBUFFER_HVS_RCV_SIZE);
> rcvbuf = min_t(int, rcvbuf, RINGBUFFER_HVS_MAX_SIZE);
>- rcvbuf = ALIGN(rcvbuf, HV_HYP_PAGE_SIZE);
>+ rcvbuf = VMBUS_RING_SIZE(rcvbuf);
> }
>
> chan->max_pkt_size = HVS_MAX_PKT_SIZE;
>--
>2.54.0
>
^ permalink raw reply
* Re: [PATCH] mshv: remove page order restriction to enable 1G hugepage support
From: Anirudh Rayabharam @ 2026-04-28 15:43 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
linux-hyperv, linux-kernel
In-Reply-To: <aeZavL_GaMyv_NWR@skinsburskii.localdomain>
On Mon, Apr 20, 2026 at 09:56:28AM -0700, Stanislav Kinsburskii wrote:
> On Thu, Apr 16, 2026 at 01:37:15PM +0000, Anirudh Rayabharam (Microsoft) wrote:
> > The hypervisor's map GPA hypercall handles large pages intelligently,
> > combining 2M pages into 1G mappings when alignment allows.
> >
> > Remove the PMD_ORDER check in mshv_chunk_stride() so that 1G hugepages
> > and other large page orders are passed through as 2M-aligned chunks,
> > letting the hypervisor promote them to 1G mappings automatically.
> >
> > Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
> > ---
> > drivers/hv/mshv_regions.c | 5 +----
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/hv/mshv_regions.c b/drivers/hv/mshv_regions.c
> > index fdffd4f002f6..5f617a96d97a 100644
> > --- a/drivers/hv/mshv_regions.c
> > +++ b/drivers/hv/mshv_regions.c
> > @@ -29,7 +29,7 @@
> > * Uses huge page stride if the backing page is huge and the guest mapping
> > * is properly aligned; otherwise falls back to single page stride.
> > *
> > - * Return: Stride in pages, or -EINVAL if page order is unsupported.
> > + * Return: Stride in pages.
> > */
> > static int mshv_chunk_stride(struct page *page,
> > u64 gfn, u64 page_count)
>
> Nit: the return type of the function should now become unsigned.
Thanks I'll prepare a v2 with this and also look into Sashiko's comments
on this patch.
Thanks,
Anirudh.
^ permalink raw reply
* Re: [PATCH] RDMA/mana_ib: validate rx_hash_key_len in mana_ib_create_qp_rss
From: Jason Gunthorpe @ 2026-04-28 16:02 UTC (permalink / raw)
To: Junrui Luo
Cc: Long Li, Konstantin Taranov, Leon Romanovsky, Dexuan Cui,
Ajay Sharma, linux-rdma, linux-hyperv, linux-kernel, Yuhao Jiang,
stable
In-Reply-To: <SYBPR01MB7881D40E494BF61A4B298252AF2C2@SYBPR01MB7881.ausprd01.prod.outlook.com>
On Tue, Apr 21, 2026 at 06:50:21PM +0800, Junrui Luo wrote:
> mana_ib_create_qp_rss() passes the user-supplied ucmd.rx_hash_key_len
> directly to mana_ib_cfg_vport_steering(), which uses it as the length
> argument to memcpy(req->hashkey, rx_hash_key, rx_hash_key_len).
>
> A value greater than MANA_HASH_KEY_SIZE leads to an out-of-bounds read
> from the kernel stack and an out-of-bounds write past req->hashkey
> within the kzalloc'd struct mana_cfg_rx_steer_req_v2.
>
> Reject any rx_hash_key_len greater than MANA_HASH_KEY_SIZE.
>
> Fixes: 0266a177631d ("RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter")
> Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
> ---
> drivers/infiniband/hw/mana/qp.c | 7 +++++++
> 1 file changed, 7 insertions(+)
I have a fix for this in my pile of sashiko patches that I prefer, it
is better to put the check in mana_ib_cfg_vport_steering() and not
print.
Jason
^ permalink raw reply
* [PATCH rc 13/15] RDMA/hns: Fix xarray race in hns_roce_create_srq()
From: Jason Gunthorpe @ 2026-04-28 16:17 UTC (permalink / raw)
To: Andrew Lunn, Broadcom internal kernel review list, Bryan Tan,
Eric Dumazet, Junxian Huang, Konstantin Taranov, Jakub Kicinski,
Leon Romanovsky, linux-hyperv, linux-rdma, netdev, Paolo Abeni,
Selvin Xavier, Chengchang Tang, Tariq Toukan, Vishnu Dasa,
Yishai Hadas
Cc: Abhijit Gangurde, Adit Ranadive, Allen Hubbe, Andrew Boyer,
Aditya Sarwade, Brad Spengler, Bryan Tan, David S. Miller,
Dexuan Cui, Doug Ledford, George Zhang, Jorgen Hansen, Jianbo Liu,
Kai Aizen, Leon Romanovsky, Leon Romanovsky, Yixian Liu, Long Li,
Lijun Ou, Parav Pandit, patches, Roland Dreier, Roland Dreier,
Sagi Grimberg, Ajay Sharma, stable, Tariq Toukan, Wei Hu (Xavier),
Shaobo Xu, Nenglong Zhao
In-Reply-To: <0-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com>
Sashiko points out that once the srq memory is stored into the xarray by
alloc_srqc() it can immediately be looked up by:
xa_lock(&srq_table->xa);
srq = xa_load(&srq_table->xa, srqn & (hr_dev->caps.num_srqs - 1));
if (srq)
refcount_inc(&srq->refcount);
xa_unlock(&srq_table->xa);
Which will fail refcount debug because the refcount is 0 and then crash:
srq->event(srq, event_type);
Because event is NULL.
Use refcount_inc_not_zero() instead to ensure a partially prepared srq is
never retrieved from the event handler and fix the ordering of the
initialization so refcount becomes 1 only after it is fully ready.
All the initialization must be done before calling free_srqc() since it
depends on the completion and refcount.
Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver")
Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=3
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/infiniband/hw/hns/hns_roce_srq.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/hw/hns/hns_roce_srq.c b/drivers/infiniband/hw/hns/hns_roce_srq.c
index cb848e8e6bbd76..8b94cbdfa54dfa 100644
--- a/drivers/infiniband/hw/hns/hns_roce_srq.c
+++ b/drivers/infiniband/hw/hns/hns_roce_srq.c
@@ -16,8 +16,8 @@ void hns_roce_srq_event(struct hns_roce_dev *hr_dev, u32 srqn, int event_type)
xa_lock(&srq_table->xa);
srq = xa_load(&srq_table->xa, srqn & (hr_dev->caps.num_srqs - 1));
- if (srq)
- refcount_inc(&srq->refcount);
+ if (srq && !refcount_inc_not_zero(&srq->refcount))
+ srq = NULL;
xa_unlock(&srq_table->xa);
if (!srq) {
@@ -470,6 +470,10 @@ int hns_roce_create_srq(struct ib_srq *ib_srq,
if (ret)
goto err_srqn;
+ srq->event = hns_roce_ib_srq_event;
+ init_completion(&srq->free);
+ refcount_set_release(&srq->refcount, 1);
+
if (udata) {
resp.cap_flags = srq->cap_flags;
resp.srqn = srq->srqn;
@@ -480,10 +484,6 @@ int hns_roce_create_srq(struct ib_srq *ib_srq,
}
}
- srq->event = hns_roce_ib_srq_event;
- refcount_set(&srq->refcount, 1);
- init_completion(&srq->free);
-
return 0;
err_srqc:
--
2.43.0
^ permalink raw reply related
* [PATCH rc 00/15] Various bug fixes for RDMA drivers in the uapi functions
From: Jason Gunthorpe @ 2026-04-28 16:17 UTC (permalink / raw)
To: Andrew Lunn, Broadcom internal kernel review list, Bryan Tan,
Eric Dumazet, Junxian Huang, Konstantin Taranov, Jakub Kicinski,
Leon Romanovsky, linux-hyperv, linux-rdma, netdev, Paolo Abeni,
Selvin Xavier, Chengchang Tang, Tariq Toukan, Vishnu Dasa,
Yishai Hadas
Cc: Abhijit Gangurde, Adit Ranadive, Allen Hubbe, Andrew Boyer,
Aditya Sarwade, Brad Spengler, Bryan Tan, David S. Miller,
Dexuan Cui, Doug Ledford, George Zhang, Jorgen Hansen, Jianbo Liu,
Kai Aizen, Leon Romanovsky, Leon Romanovsky, Yixian Liu, Long Li,
Lijun Ou, Parav Pandit, patches, Roland Dreier, Roland Dreier,
Sagi Grimberg, Ajay Sharma, stable, Tariq Toukan, Wei Hu (Xavier),
Shaobo Xu, Nenglong Zhao
All were found by Sashiko or Claude AI tools. They vary in severity, but
are all things that shouldn't be present.
Jason Gunthorpe (15):
RDMA/ionic: Fix typo in format string
RDMA/mlx5: Restore zero-init to mlx5_ib_modify_qp() ucmd
RDMA/mlx5: Add missing store/release for lock elision pattern
RDMA/mana: Validate rx_hash_key_len
RDMA/mana: Remove user triggerable WARN_ON() in
mana_ib_create_qp_rss()
RDMA/mana: Fix mana_destroy_wq_obj() cleanup in
mana_ib_create_qp_rss()
RDMA/mana: Fix error unwind in mana_ib_create_qp_rss()
RDMA/ocrdma: Clarify the mm_head searching
RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp()
RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path
RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()
RDMA/mlx4: Fix mis-use of RCU in mlx4_srq_event()
RDMA/hns: Fix xarray race in hns_roce_create_srq()
RDMA/hns: Fix xarray race in hns_roce_create_qp_common()
RDMA/hns: Fix unlocked call to hns_roce_qp_remove()
drivers/infiniband/hw/hns/hns_roce_qp.c | 13 ++++++++++---
drivers/infiniband/hw/hns/hns_roce_srq.c | 12 ++++++------
drivers/infiniband/hw/ionic/ionic_ibdev.c | 2 +-
drivers/infiniband/hw/mana/cq.c | 5 +++--
drivers/infiniband/hw/mana/qp.c | 16 ++++++++++------
drivers/infiniband/hw/mlx4/srq.c | 4 +++-
drivers/infiniband/hw/mlx5/main.c | 8 ++++----
drivers/infiniband/hw/mlx5/qp.c | 2 +-
drivers/infiniband/hw/mlx5/umr.c | 4 ++--
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 8 ++++----
drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/srq.c | 13 +++++++------
12 files changed, 52 insertions(+), 37 deletions(-)
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
--
2.43.0
^ permalink raw reply
* [PATCH rc 06/15] RDMA/mana: Fix mana_destroy_wq_obj() cleanup in mana_ib_create_qp_rss()
From: Jason Gunthorpe @ 2026-04-28 16:17 UTC (permalink / raw)
To: Andrew Lunn, Broadcom internal kernel review list, Bryan Tan,
Eric Dumazet, Junxian Huang, Konstantin Taranov, Jakub Kicinski,
Leon Romanovsky, linux-hyperv, linux-rdma, netdev, Paolo Abeni,
Selvin Xavier, Chengchang Tang, Tariq Toukan, Vishnu Dasa,
Yishai Hadas
Cc: Abhijit Gangurde, Adit Ranadive, Allen Hubbe, Andrew Boyer,
Aditya Sarwade, Brad Spengler, Bryan Tan, David S. Miller,
Dexuan Cui, Doug Ledford, George Zhang, Jorgen Hansen, Jianbo Liu,
Kai Aizen, Leon Romanovsky, Leon Romanovsky, Yixian Liu, Long Li,
Lijun Ou, Parav Pandit, patches, Roland Dreier, Roland Dreier,
Sagi Grimberg, Ajay Sharma, stable, Tariq Toukan, Wei Hu (Xavier),
Shaobo Xu, Nenglong Zhao
In-Reply-To: <0-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com>
Sashiko points out there are two bugs here in the error unwind flow, both
related to how the WQ table is unwound.
First there is a double i-- on the first failure path due to the while loop
having a i--, remove it.
Second if mana_ib_install_cq_cb() fails then mana_create_wq_obj() is not
undone due to the above i--.
Cc: stable@vger.kernel.org
Fixes: c15d7802a424 ("RDMA/mana_ib: Add CQ interrupt support for RAW QP")
Link: https://sashiko.dev/#/patchset/0-v2-1c49eeb88c48%2B91-rdma_udata_rep_jgg%40nvidia.com?part=1
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/infiniband/hw/mana/qp.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/hw/mana/qp.c b/drivers/infiniband/hw/mana/qp.c
index f7bb0d1f0f8034..8e1f052d0ec976 100644
--- a/drivers/infiniband/hw/mana/qp.c
+++ b/drivers/infiniband/hw/mana/qp.c
@@ -176,11 +176,8 @@ static int mana_ib_create_qp_rss(struct ib_qp *ibqp, struct ib_pd *pd,
ret = mana_create_wq_obj(mpc, mpc->port_handle, GDMA_RQ,
&wq_spec, &cq_spec, &wq->rx_object);
- if (ret) {
- /* Do cleanup starting with index i-1 */
- i--;
+ if (ret)
goto fail;
- }
/* The GDMA regions are now owned by the WQ object */
wq->queue.gdma_region = GDMA_INVALID_DMA_REGION;
@@ -200,8 +197,10 @@ static int mana_ib_create_qp_rss(struct ib_qp *ibqp, struct ib_pd *pd,
/* Create CQ table entry */
ret = mana_ib_install_cq_cb(mdev, cq);
- if (ret)
+ if (ret) {
+ mana_destroy_wq_obj(mpc, GDMA_RQ, wq->rx_object);
goto fail;
+ }
}
resp.num_entries = i;
--
2.43.0
^ permalink raw reply related
* [PATCH rc 02/15] RDMA/mlx5: Restore zero-init to mlx5_ib_modify_qp() ucmd
From: Jason Gunthorpe @ 2026-04-28 16:17 UTC (permalink / raw)
To: Andrew Lunn, Broadcom internal kernel review list, Bryan Tan,
Eric Dumazet, Junxian Huang, Konstantin Taranov, Jakub Kicinski,
Leon Romanovsky, linux-hyperv, linux-rdma, netdev, Paolo Abeni,
Selvin Xavier, Chengchang Tang, Tariq Toukan, Vishnu Dasa,
Yishai Hadas
Cc: Abhijit Gangurde, Adit Ranadive, Allen Hubbe, Andrew Boyer,
Aditya Sarwade, Brad Spengler, Bryan Tan, David S. Miller,
Dexuan Cui, Doug Ledford, George Zhang, Jorgen Hansen, Jianbo Liu,
Kai Aizen, Leon Romanovsky, Leon Romanovsky, Yixian Liu, Long Li,
Lijun Ou, Parav Pandit, patches, Roland Dreier, Roland Dreier,
Sagi Grimberg, Ajay Sharma, stable, Tariq Toukan, Wei Hu (Xavier),
Shaobo Xu, Nenglong Zhao
In-Reply-To: <0-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com>
Sashiko points out the check for inlen==0 got missed, the ={} was not
redundant, put it back.
Fixes: a9cd442a5347 ("RDMA: Remove redundant = {} for udata req structs")
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/infiniband/hw/mlx5/qp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
index 8f50e7342a7694..76d4021475f49b 100644
--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -4692,7 +4692,7 @@ int mlx5_ib_modify_qp(struct ib_qp *ibqp, struct ib_qp_attr *attr,
struct mlx5_ib_dev *dev = to_mdev(ibqp->device);
struct mlx5_ib_modify_qp_resp resp = {};
struct mlx5_ib_qp *qp = to_mqp(ibqp);
- struct mlx5_ib_modify_qp ucmd;
+ struct mlx5_ib_modify_qp ucmd = {};
enum ib_qp_type qp_type;
enum ib_qp_state cur_state, new_state;
int err = -EINVAL;
--
2.43.0
^ permalink raw reply related
* [PATCH rc 07/15] RDMA/mana: Fix error unwind in mana_ib_create_qp_rss()
From: Jason Gunthorpe @ 2026-04-28 16:17 UTC (permalink / raw)
To: Andrew Lunn, Broadcom internal kernel review list, Bryan Tan,
Eric Dumazet, Junxian Huang, Konstantin Taranov, Jakub Kicinski,
Leon Romanovsky, linux-hyperv, linux-rdma, netdev, Paolo Abeni,
Selvin Xavier, Chengchang Tang, Tariq Toukan, Vishnu Dasa,
Yishai Hadas
Cc: Abhijit Gangurde, Adit Ranadive, Allen Hubbe, Andrew Boyer,
Aditya Sarwade, Brad Spengler, Bryan Tan, David S. Miller,
Dexuan Cui, Doug Ledford, George Zhang, Jorgen Hansen, Jianbo Liu,
Kai Aizen, Leon Romanovsky, Leon Romanovsky, Yixian Liu, Long Li,
Lijun Ou, Parav Pandit, patches, Roland Dreier, Roland Dreier,
Sagi Grimberg, Ajay Sharma, stable, Tariq Toukan, Wei Hu (Xavier),
Shaobo Xu, Nenglong Zhao
In-Reply-To: <0-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com>
Sashiko points out that mana_ib_cfg_vport_steering() is leaked, the normal
destroy path cleans it up.
Cc: stable@vger.kernel.org
Fixes: 0266a177631d ("RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter")
Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=4
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/infiniband/hw/mana/qp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mana/qp.c b/drivers/infiniband/hw/mana/qp.c
index 8e1f052d0ec976..0fbcf449c134b5 100644
--- a/drivers/infiniband/hw/mana/qp.c
+++ b/drivers/infiniband/hw/mana/qp.c
@@ -217,13 +217,15 @@ static int mana_ib_create_qp_rss(struct ib_qp *ibqp, struct ib_pd *pd,
ibdev_dbg(&mdev->ib_dev,
"Failed to copy to udata create rss-qp, %d\n",
ret);
- goto fail;
+ goto err_disable_vport_rx;
}
kfree(mana_ind_table);
return 0;
+err_disable_vport_rx:
+ mana_disable_vport_rx(mpc);
fail:
while (i-- > 0) {
ibwq = ind_tbl->ind_tbl[i];
--
2.43.0
^ permalink raw reply related
* [PATCH rc 04/15] RDMA/mana: Validate rx_hash_key_len
From: Jason Gunthorpe @ 2026-04-28 16:17 UTC (permalink / raw)
To: Andrew Lunn, Broadcom internal kernel review list, Bryan Tan,
Eric Dumazet, Junxian Huang, Konstantin Taranov, Jakub Kicinski,
Leon Romanovsky, linux-hyperv, linux-rdma, netdev, Paolo Abeni,
Selvin Xavier, Chengchang Tang, Tariq Toukan, Vishnu Dasa,
Yishai Hadas
Cc: Abhijit Gangurde, Adit Ranadive, Allen Hubbe, Andrew Boyer,
Aditya Sarwade, Brad Spengler, Bryan Tan, David S. Miller,
Dexuan Cui, Doug Ledford, George Zhang, Jorgen Hansen, Jianbo Liu,
Kai Aizen, Leon Romanovsky, Leon Romanovsky, Yixian Liu, Long Li,
Lijun Ou, Parav Pandit, patches, Roland Dreier, Roland Dreier,
Sagi Grimberg, Ajay Sharma, stable, Tariq Toukan, Wei Hu (Xavier),
Shaobo Xu, Nenglong Zhao
In-Reply-To: <0-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com>
Sashiko points out that rx_hash_key_len comes from a uAPI structure and is
blindly passed to memcpy, allowing the userspace to trash kernel
memory. Bounds check it so the memcpy cannot overflow.
Cc: stable@vger.kernel.org
Fixes: 0266a177631d ("RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter")
Link: https://sashiko.dev/#/patchset/0-v2-1c49eeb88c48%2B91-rdma_udata_rep_jgg%40nvidia.com?part=1
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/infiniband/hw/mana/qp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/infiniband/hw/mana/qp.c b/drivers/infiniband/hw/mana/qp.c
index 645581359cee0b..f7bb0d1f0f8034 100644
--- a/drivers/infiniband/hw/mana/qp.c
+++ b/drivers/infiniband/hw/mana/qp.c
@@ -21,6 +21,9 @@ static int mana_ib_cfg_vport_steering(struct mana_ib_dev *dev,
gc = mdev_to_gc(dev);
+ if (rx_hash_key_len > sizeof(req->hashkey))
+ return -EINVAL;
+
req_buf_size = struct_size(req, indir_tab, MANA_INDIRECT_TABLE_DEF_SIZE);
req = kzalloc(req_buf_size, GFP_KERNEL);
if (!req)
--
2.43.0
^ permalink raw reply related
* [PATCH rc 08/15] RDMA/ocrdma: Clarify the mm_head searching
From: Jason Gunthorpe @ 2026-04-28 16:17 UTC (permalink / raw)
To: Andrew Lunn, Broadcom internal kernel review list, Bryan Tan,
Eric Dumazet, Junxian Huang, Konstantin Taranov, Jakub Kicinski,
Leon Romanovsky, linux-hyperv, linux-rdma, netdev, Paolo Abeni,
Selvin Xavier, Chengchang Tang, Tariq Toukan, Vishnu Dasa,
Yishai Hadas
Cc: Abhijit Gangurde, Adit Ranadive, Allen Hubbe, Andrew Boyer,
Aditya Sarwade, Brad Spengler, Bryan Tan, David S. Miller,
Dexuan Cui, Doug Ledford, George Zhang, Jorgen Hansen, Jianbo Liu,
Kai Aizen, Leon Romanovsky, Leon Romanovsky, Yixian Liu, Long Li,
Lijun Ou, Parav Pandit, patches, Roland Dreier, Roland Dreier,
Sagi Grimberg, Ajay Sharma, stable, Tariq Toukan, Wei Hu (Xavier),
Shaobo Xu, Nenglong Zhao
In-Reply-To: <0-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com>
The intention of this code is to find matching entries exactly, the driver
never creates phys_addr's with different lens so the current expression is
not a bug, but it doesn't make sense and confuses review tooling.
Search for exact match instead.
Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=4
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
index c17e2a54dbcaf9..463c9a5703fc4e 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
@@ -215,7 +215,7 @@ static void ocrdma_del_mmap(struct ocrdma_ucontext *uctx, u64 phy_addr,
mutex_lock(&uctx->mm_list_lock);
list_for_each_entry_safe(mm, tmp, &uctx->mm_head, entry) {
- if (len != mm->key.len && phy_addr != mm->key.phy_addr)
+ if (len != mm->key.len || phy_addr != mm->key.phy_addr)
continue;
list_del(&mm->entry);
@@ -233,7 +233,7 @@ static bool ocrdma_search_mmap(struct ocrdma_ucontext *uctx, u64 phy_addr,
mutex_lock(&uctx->mm_list_lock);
list_for_each_entry(mm, &uctx->mm_head, entry) {
- if (len != mm->key.len && phy_addr != mm->key.phy_addr)
+ if (len != mm->key.len || phy_addr != mm->key.phy_addr)
continue;
found = true;
--
2.43.0
^ permalink raw reply related
* [PATCH rc 15/15] RDMA/hns: Fix unlocked call to hns_roce_qp_remove()
From: Jason Gunthorpe @ 2026-04-28 16:17 UTC (permalink / raw)
To: Andrew Lunn, Broadcom internal kernel review list, Bryan Tan,
Eric Dumazet, Junxian Huang, Konstantin Taranov, Jakub Kicinski,
Leon Romanovsky, linux-hyperv, linux-rdma, netdev, Paolo Abeni,
Selvin Xavier, Chengchang Tang, Tariq Toukan, Vishnu Dasa,
Yishai Hadas
Cc: Abhijit Gangurde, Adit Ranadive, Allen Hubbe, Andrew Boyer,
Aditya Sarwade, Brad Spengler, Bryan Tan, David S. Miller,
Dexuan Cui, Doug Ledford, George Zhang, Jorgen Hansen, Jianbo Liu,
Kai Aizen, Leon Romanovsky, Leon Romanovsky, Yixian Liu, Long Li,
Lijun Ou, Parav Pandit, patches, Roland Dreier, Roland Dreier,
Sagi Grimberg, Ajay Sharma, stable, Tariq Toukan, Wei Hu (Xavier),
Shaobo Xu, Nenglong Zhao
In-Reply-To: <0-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com>
Sashiko points out that hns_roce_qp_remove() requires the caller to hold
locks. The error flow in hns_roce_create_qp_common() doesn't hold those
locks for the error unwind so it risks corrupting memory.
Grab the same locks the other two callers use.
Cc: stable@vger.kernel.org
Fixes: e088a685eae9 ("RDMA/hns: Support rq record doorbell for the user space")
Link: https://sashiko.dev/#/patchset/0-v2-1c49eeb88c48%2B91-rdma_udata_rep_jgg%40nvidia.com?part=9
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/infiniband/hw/hns/hns_roce_qp.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/infiniband/hw/hns/hns_roce_qp.c b/drivers/infiniband/hw/hns/hns_roce_qp.c
index f94ba98871f0d0..bf04ee84a94392 100644
--- a/drivers/infiniband/hw/hns/hns_roce_qp.c
+++ b/drivers/infiniband/hw/hns/hns_roce_qp.c
@@ -1171,6 +1171,7 @@ static int hns_roce_create_qp_common(struct hns_roce_dev *hr_dev,
struct hns_roce_ib_create_qp_resp resp = {};
struct ib_device *ibdev = &hr_dev->ib_dev;
struct hns_roce_ib_create_qp ucmd = {};
+ unsigned long flags;
int ret;
mutex_init(&hr_qp->mutex);
@@ -1257,7 +1258,13 @@ static int hns_roce_create_qp_common(struct hns_roce_dev *hr_dev,
return 0;
err_flow_ctrl:
+ spin_lock_irqsave(&hr_dev->qp_list_lock, flags);
+ hns_roce_lock_cqs(init_attr->send_cq ? to_hr_cq(init_attr->send_cq) : NULL,
+ init_attr->recv_cq ? to_hr_cq(init_attr->recv_cq) : NULL);
hns_roce_qp_remove(hr_dev, hr_qp);
+ hns_roce_unlock_cqs(init_attr->send_cq ? to_hr_cq(init_attr->send_cq) : NULL,
+ init_attr->recv_cq ? to_hr_cq(init_attr->recv_cq) : NULL);
+ spin_unlock_irqrestore(&hr_dev->qp_list_lock, flags);
err_store:
free_qpc(hr_dev, hr_qp);
err_qpc:
--
2.43.0
^ permalink raw reply related
* [PATCH rc 05/15] RDMA/mana: Remove user triggerable WARN_ON() in mana_ib_create_qp_rss()
From: Jason Gunthorpe @ 2026-04-28 16:17 UTC (permalink / raw)
To: Andrew Lunn, Broadcom internal kernel review list, Bryan Tan,
Eric Dumazet, Junxian Huang, Konstantin Taranov, Jakub Kicinski,
Leon Romanovsky, linux-hyperv, linux-rdma, netdev, Paolo Abeni,
Selvin Xavier, Chengchang Tang, Tariq Toukan, Vishnu Dasa,
Yishai Hadas
Cc: Abhijit Gangurde, Adit Ranadive, Allen Hubbe, Andrew Boyer,
Aditya Sarwade, Brad Spengler, Bryan Tan, David S. Miller,
Dexuan Cui, Doug Ledford, George Zhang, Jorgen Hansen, Jianbo Liu,
Kai Aizen, Leon Romanovsky, Leon Romanovsky, Yixian Liu, Long Li,
Lijun Ou, Parav Pandit, patches, Roland Dreier, Roland Dreier,
Sagi Grimberg, Ajay Sharma, stable, Tariq Toukan, Wei Hu (Xavier),
Shaobo Xu, Nenglong Zhao
In-Reply-To: <0-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com>
Sashiko points out that the user can specify WQs sharing the same CQ as a
part of the uAPI and this will trigger the WARN_ON() then go on to corrupt
the kernel.
Just reject it outright and fail the QP creation.
Cc: stable@vger.kernel.org
Fixes: c15d7802a424 ("RDMA/mana_ib: Add CQ interrupt support for RAW QP")
Link: https://sashiko.dev/#/patchset/0-v2-1c49eeb88c48%2B91-rdma_udata_rep_jgg%40nvidia.com?part=1
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/infiniband/hw/mana/cq.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/mana/cq.c b/drivers/infiniband/hw/mana/cq.c
index f4cbe21763bf11..2d682428ef202a 100644
--- a/drivers/infiniband/hw/mana/cq.c
+++ b/drivers/infiniband/hw/mana/cq.c
@@ -137,8 +137,9 @@ int mana_ib_install_cq_cb(struct mana_ib_dev *mdev, struct mana_ib_cq *cq)
if (cq->queue.id >= gc->max_num_cqs)
return -EINVAL;
- /* Create CQ table entry */
- WARN_ON(gc->cq_table[cq->queue.id]);
+ /* Create CQ table entry, sharing a CQ between WQs is not supported */
+ if (gc->cq_table[cq->queue.id])
+ return -EINVAL;
if (cq->queue.kmem)
gdma_cq = cq->queue.kmem;
else
--
2.43.0
^ permalink raw reply related
* [PATCH rc 11/15] RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()
From: Jason Gunthorpe @ 2026-04-28 16:17 UTC (permalink / raw)
To: Andrew Lunn, Broadcom internal kernel review list, Bryan Tan,
Eric Dumazet, Junxian Huang, Konstantin Taranov, Jakub Kicinski,
Leon Romanovsky, linux-hyperv, linux-rdma, netdev, Paolo Abeni,
Selvin Xavier, Chengchang Tang, Tariq Toukan, Vishnu Dasa,
Yishai Hadas
Cc: Abhijit Gangurde, Adit Ranadive, Allen Hubbe, Andrew Boyer,
Aditya Sarwade, Brad Spengler, Bryan Tan, David S. Miller,
Dexuan Cui, Doug Ledford, George Zhang, Jorgen Hansen, Jianbo Liu,
Kai Aizen, Leon Romanovsky, Leon Romanovsky, Yixian Liu, Long Li,
Lijun Ou, Parav Pandit, patches, Roland Dreier, Roland Dreier,
Sagi Grimberg, Ajay Sharma, stable, Tariq Toukan, Wei Hu (Xavier),
Shaobo Xu, Nenglong Zhao
In-Reply-To: <0-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com>
Sashiko points out that mlx4_srq_alloc() was not undone during error
unwind, add the missing call to mlx4_srq_free().
Cc: stable@vger.kernel.org
Fixes: 225c7b1feef1 ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters")
Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=8
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/infiniband/hw/mlx4/srq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx4/srq.c b/drivers/infiniband/hw/mlx4/srq.c
index 5b23e5f8b84aca..767840736d583b 100644
--- a/drivers/infiniband/hw/mlx4/srq.c
+++ b/drivers/infiniband/hw/mlx4/srq.c
@@ -194,13 +194,15 @@ int mlx4_ib_create_srq(struct ib_srq *ib_srq,
if (udata)
if (ib_copy_to_udata(udata, &srq->msrq.srqn, sizeof (__u32))) {
err = -EFAULT;
- goto err_wrid;
+ goto err_srq;
}
init_attr->attr.max_wr = srq->msrq.max - 1;
return 0;
+err_srq:
+ mlx4_srq_free(dev->dev, &srq->msrq);
err_wrid:
if (udata)
mlx4_ib_db_unmap_user(ucontext, &srq->db);
--
2.43.0
^ permalink raw reply related
* [PATCH rc 03/15] RDMA/mlx5: Add missing store/release for lock elision pattern
From: Jason Gunthorpe @ 2026-04-28 16:17 UTC (permalink / raw)
To: Andrew Lunn, Broadcom internal kernel review list, Bryan Tan,
Eric Dumazet, Junxian Huang, Konstantin Taranov, Jakub Kicinski,
Leon Romanovsky, linux-hyperv, linux-rdma, netdev, Paolo Abeni,
Selvin Xavier, Chengchang Tang, Tariq Toukan, Vishnu Dasa,
Yishai Hadas
Cc: Abhijit Gangurde, Adit Ranadive, Allen Hubbe, Andrew Boyer,
Aditya Sarwade, Brad Spengler, Bryan Tan, David S. Miller,
Dexuan Cui, Doug Ledford, George Zhang, Jorgen Hansen, Jianbo Liu,
Kai Aizen, Leon Romanovsky, Leon Romanovsky, Yixian Liu, Long Li,
Lijun Ou, Parav Pandit, patches, Roland Dreier, Roland Dreier,
Sagi Grimberg, Ajay Sharma, stable, Tariq Toukan, Wei Hu (Xavier),
Shaobo Xu, Nenglong Zhao
In-Reply-To: <0-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com>
mlx5 has a common pattern implementing a device-global singleton resource
where it checks the resource pointer for !NULL and then skips obtaining
the lock.
This is not ordered properly as observing !NULL doesn't mean that all the
data under that pointer is also visible on this CPU when the lock is not
taken.
Use a release/acquire pairing to explicitly manage this.
Pointed out by sashiko, Codex found more cases.
Fixes: 5895e70f2e6e ("IB/mlx5: Allocate resources just before first QP/SRQ is created")
Fixes: 638420115cc4 ("IB/mlx5: Create UMR QP just before first reg_mr occurs")
Link: https://sashiko.dev/#/patchset/SYBPR01MB7881E1E0970268BD69C0BA75AF2B2%40SYBPR01MB7881.ausprd01.prod.outlook.com
Assisted-by: Codex:GPT-5.5
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/infiniband/hw/mlx5/main.c | 8 ++++----
drivers/infiniband/hw/mlx5/umr.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
index 109661c2ac12b0..73fab8a376933d 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -3310,7 +3310,7 @@ int mlx5_ib_dev_res_cq_init(struct mlx5_ib_dev *dev)
* devr->c0 is set once, never changed until device unload.
* Avoid taking the mutex if initialization is already done.
*/
- if (devr->c0)
+ if (smp_load_acquire(&devr->c0))
return 0;
mutex_lock(&devr->cq_lock);
@@ -3336,7 +3336,7 @@ int mlx5_ib_dev_res_cq_init(struct mlx5_ib_dev *dev)
}
devr->p0 = pd;
- devr->c0 = cq;
+ smp_store_release(&devr->c0, cq);
unlock:
mutex_unlock(&devr->cq_lock);
@@ -3354,7 +3354,7 @@ int mlx5_ib_dev_res_srq_init(struct mlx5_ib_dev *dev)
* devr->s1 is set once, never changed until device unload.
* Avoid taking the mutex if initialization is already done.
*/
- if (devr->s1)
+ if (smp_load_acquire(&devr->s1))
return 0;
mutex_lock(&devr->srq_lock);
@@ -3395,7 +3395,7 @@ int mlx5_ib_dev_res_srq_init(struct mlx5_ib_dev *dev)
}
devr->s0 = s0;
- devr->s1 = s1;
+ smp_store_release(&devr->s1, s1);
unlock:
mutex_unlock(&devr->srq_lock);
diff --git a/drivers/infiniband/hw/mlx5/umr.c b/drivers/infiniband/hw/mlx5/umr.c
index 29488fba21a034..f2139474be3751 100644
--- a/drivers/infiniband/hw/mlx5/umr.c
+++ b/drivers/infiniband/hw/mlx5/umr.c
@@ -147,7 +147,7 @@ int mlx5r_umr_resource_init(struct mlx5_ib_dev *dev)
* UMR qp is set once, never changed until device unload.
* Avoid taking the mutex if initialization is already done.
*/
- if (dev->umrc.qp)
+ if (smp_load_acquire(&dev->umrc.qp))
return 0;
mutex_lock(&dev->umrc.init_lock);
@@ -185,7 +185,7 @@ int mlx5r_umr_resource_init(struct mlx5_ib_dev *dev)
sema_init(&dev->umrc.sem, MAX_UMR_WR);
mutex_init(&dev->umrc.lock);
dev->umrc.state = MLX5_UMR_STATE_ACTIVE;
- dev->umrc.qp = qp;
+ smp_store_release(&dev->umrc.qp, qp);
mutex_unlock(&dev->umrc.init_lock);
return 0;
--
2.43.0
^ permalink raw reply related
* [PATCH rc 10/15] RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path
From: Jason Gunthorpe @ 2026-04-28 16:17 UTC (permalink / raw)
To: Andrew Lunn, Broadcom internal kernel review list, Bryan Tan,
Eric Dumazet, Junxian Huang, Konstantin Taranov, Jakub Kicinski,
Leon Romanovsky, linux-hyperv, linux-rdma, netdev, Paolo Abeni,
Selvin Xavier, Chengchang Tang, Tariq Toukan, Vishnu Dasa,
Yishai Hadas
Cc: Abhijit Gangurde, Adit Ranadive, Allen Hubbe, Andrew Boyer,
Aditya Sarwade, Brad Spengler, Bryan Tan, David S. Miller,
Dexuan Cui, Doug Ledford, George Zhang, Jorgen Hansen, Jianbo Liu,
Kai Aizen, Leon Romanovsky, Leon Romanovsky, Yixian Liu, Long Li,
Lijun Ou, Parav Pandit, patches, Roland Dreier, Roland Dreier,
Sagi Grimberg, Ajay Sharma, stable, Tariq Toukan, Wei Hu (Xavier),
Shaobo Xu, Nenglong Zhao
In-Reply-To: <0-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com>
Sashiko points out that pvrdma_uar_free() is already called within
pvrdma_dealloc_ucontext(), so calling it before triggers a double free.
Cc: stable@vger.kernel.org
Fixes: 29c8d9eba550 ("IB: Add vmw_pvrdma driver")
Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=4
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c
index bcd43dc30e21c6..c7c2b41060e526 100644
--- a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c
+++ b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c
@@ -322,7 +322,7 @@ int pvrdma_alloc_ucontext(struct ib_ucontext *uctx, struct ib_udata *udata)
uresp.qp_tab_size = vdev->dsr->caps.max_qp;
ret = ib_copy_to_udata(udata, &uresp, sizeof(uresp));
if (ret) {
- pvrdma_uar_free(vdev, &context->uar);
+ /* pvrdma_dealloc_ucontext() also frees the UAR */
pvrdma_dealloc_ucontext(&context->ibucontext);
return -EFAULT;
}
--
2.43.0
^ permalink raw reply related
* [PATCH rc 12/15] RDMA/mlx4: Fix mis-use of RCU in mlx4_srq_event()
From: Jason Gunthorpe @ 2026-04-28 16:17 UTC (permalink / raw)
To: Andrew Lunn, Broadcom internal kernel review list, Bryan Tan,
Eric Dumazet, Junxian Huang, Konstantin Taranov, Jakub Kicinski,
Leon Romanovsky, linux-hyperv, linux-rdma, netdev, Paolo Abeni,
Selvin Xavier, Chengchang Tang, Tariq Toukan, Vishnu Dasa,
Yishai Hadas
Cc: Abhijit Gangurde, Adit Ranadive, Allen Hubbe, Andrew Boyer,
Aditya Sarwade, Brad Spengler, Bryan Tan, David S. Miller,
Dexuan Cui, Doug Ledford, George Zhang, Jorgen Hansen, Jianbo Liu,
Kai Aizen, Leon Romanovsky, Leon Romanovsky, Yixian Liu, Long Li,
Lijun Ou, Parav Pandit, patches, Roland Dreier, Roland Dreier,
Sagi Grimberg, Ajay Sharma, stable, Tariq Toukan, Wei Hu (Xavier),
Shaobo Xu, Nenglong Zhao
In-Reply-To: <0-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com>
Sashiko points out the radix_tree itself is RCU safe, but nothing ever
frees the mlx4_srq struct with RCU, and it isn't even accessed within the
RCU critical section. It also will crash if an event is delivered before
the srq object is finished initializing.
Use the spinlock since it isn't easy to make RCU work, use
refcount_inc_not_zero() to protect against partially initialized objects,
and order the refcount_set() to be after the srq is fully initialized.
Cc: stable@vger.kernel.org
Fixes: 30353bfc43a1 ("net/mlx4_core: Use RCU to perform radix tree lookup for SRQ")
Link: https://sashiko.dev/#/patchset/0-v2-1c49eeb88c48%2B91-rdma_udata_rep_jgg%40nvidia.com?part=5
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx4/srq.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/srq.c b/drivers/net/ethernet/mellanox/mlx4/srq.c
index dd890f5d7b725c..8711689120f302 100644
--- a/drivers/net/ethernet/mellanox/mlx4/srq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/srq.c
@@ -44,13 +44,14 @@ void mlx4_srq_event(struct mlx4_dev *dev, u32 srqn, int event_type)
{
struct mlx4_srq_table *srq_table = &mlx4_priv(dev)->srq_table;
struct mlx4_srq *srq;
+ unsigned long flags;
- rcu_read_lock();
+ spin_lock_irqsave(&srq_table->lock, flags);
srq = radix_tree_lookup(&srq_table->tree, srqn & (dev->caps.num_srqs - 1));
- rcu_read_unlock();
- if (srq)
- refcount_inc(&srq->refcount);
- else {
+ if (!srq || !refcount_inc_not_zero(&srq->refcount))
+ srq = NULL;
+ spin_unlock_irqrestore(&srq_table->lock, flags);
+ if (!srq) {
mlx4_warn(dev, "Async event for bogus SRQ %08x\n", srqn);
return;
}
@@ -203,8 +204,8 @@ int mlx4_srq_alloc(struct mlx4_dev *dev, u32 pdn, u32 cqn, u16 xrcd,
if (err)
goto err_radix;
- refcount_set(&srq->refcount, 1);
init_completion(&srq->free);
+ refcount_set_release(&srq->refcount, 1);
return 0;
--
2.43.0
^ permalink raw reply related
* [PATCH rc 09/15] RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp()
From: Jason Gunthorpe @ 2026-04-28 16:17 UTC (permalink / raw)
To: Andrew Lunn, Broadcom internal kernel review list, Bryan Tan,
Eric Dumazet, Junxian Huang, Konstantin Taranov, Jakub Kicinski,
Leon Romanovsky, linux-hyperv, linux-rdma, netdev, Paolo Abeni,
Selvin Xavier, Chengchang Tang, Tariq Toukan, Vishnu Dasa,
Yishai Hadas
Cc: Abhijit Gangurde, Adit Ranadive, Allen Hubbe, Andrew Boyer,
Aditya Sarwade, Brad Spengler, Bryan Tan, David S. Miller,
Dexuan Cui, Doug Ledford, George Zhang, Jorgen Hansen, Jianbo Liu,
Kai Aizen, Leon Romanovsky, Leon Romanovsky, Yixian Liu, Long Li,
Lijun Ou, Parav Pandit, patches, Roland Dreier, Roland Dreier,
Sagi Grimberg, Ajay Sharma, stable, Tariq Toukan, Wei Hu (Xavier),
Shaobo Xu, Nenglong Zhao
In-Reply-To: <0-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com>
Sashiko points out that pd->uctx isn't initialized until late in the
function so all these error flow references are NULL and will crash. Use
the uctx that isn't NULL.
Cc: stable@vger.kernel.org
Fixes: fe2caefcdf58 ("RDMA/ocrdma: Add driver for Emulex OneConnect IBoE RDMA adapter")
Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=4
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
index 463c9a5703fc4e..a88cc5d84af828 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
@@ -620,9 +620,9 @@ static int ocrdma_copy_pd_uresp(struct ocrdma_dev *dev, struct ocrdma_pd *pd,
ucopy_err:
if (pd->dpp_enabled)
- ocrdma_del_mmap(pd->uctx, dpp_page_addr, PAGE_SIZE);
+ ocrdma_del_mmap(uctx, dpp_page_addr, PAGE_SIZE);
dpp_map_err:
- ocrdma_del_mmap(pd->uctx, db_page_addr, db_page_size);
+ ocrdma_del_mmap(uctx, db_page_addr, db_page_size);
return status;
}
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox