* Re: (subset) [PATCH rdma-next 0/2] RDMA: Small batch of cleanups
From: Leon Romanovsky @ 2026-07-14 6:53 UTC (permalink / raw)
To: Selvin Xavier, Kalesh AP, Jason Gunthorpe, Michael Margolin,
Gal Pressman, Yossi Leybovich, Cheng Xu, Kai Shen,
Chengchang Tang, Junxian Huang, Tatyana Nikolova, Long Li,
Konstantin Taranov, Yishai Hadas, Michal Kalderon, Nelson Escobar,
Satish Kharat, Bernard Metzler, Leon Romanovsky
Cc: linux-rdma, linux-kernel, linux-hyperv
In-Reply-To: <20260713-fix-destroy-no-udata-v1-0-fcca2e34fd57@nvidia.com>
On Mon, 13 Jul 2026 11:10:33 +0300, Leon Romanovsky wrote:
> This series contains two independent cleanups. One fixes the problematic placemen
> of a newly introduced in-kernel API, which should be called at the beginning of
> destroy functions and not at the end. The other removes a redundant memset().
>
> Thanks.
>
>
> [...]
Applied, thanks!
[2/2] RDMA: Remove redundant memset() from query_device callbacks
https://git.kernel.org/rdma/rdma/c/eeb9697db6c16d
Best regards,
--
Leon Romanovsky <leon@kernel.org>
^ permalink raw reply
* Re: [PATCH rdma-next 1/2] RDMA/bnxt_re: Validate udata before destroying resources
From: Selvin Xavier @ 2026-07-14 6:50 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Jacob Moroni, Kalesh AP, Jason Gunthorpe, Michael Margolin,
Gal Pressman, Yossi Leybovich, Cheng Xu, Kai Shen,
Chengchang Tang, Junxian Huang, Tatyana Nikolova, Long Li,
Konstantin Taranov, Yishai Hadas, Michal Kalderon, Nelson Escobar,
Satish Kharat, Bernard Metzler, linux-rdma, linux-kernel,
linux-hyperv
In-Reply-To: <20260713145608.GO33197@unreal>
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]
On Mon, Jul 13, 2026 at 8:26 PM Leon Romanovsky <leon@kernel.org> wrote:
>
> On Mon, Jul 13, 2026 at 10:21:49AM -0400, Jacob Moroni wrote:
> > These changes look good but there is also a call to ib_respond_empty_udata
> > in bnxt_re_resize_cq (but that method does take input data).
> >
> > Is that one a problem? I guess the resize could complete but the upper
> > layers would think it failed if the ib_respond_empty_udata call fails?
>
> I think that modify verbs should be fixed too.
>
> >
> > Reviewed-by: Jacob Moroni <jmoroni@google.com>
Acked-by: Selvin Xavier <selvin.xavier@broadcom.com>
Thanks
>
> Thanks
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5473 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/4] iommu/hyperv: Add para-virtualized IOMMU support for Hyper-V guest
From: Yu Zhang @ 2026-07-14 3:34 UTC (permalink / raw)
To: Michael Kelley
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
iommu@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arch@vger.kernel.org, wei.liu@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, decui@microsoft.com, longli@microsoft.com,
joro@8bytes.org, will@kernel.org, robin.murphy@arm.com,
bhelgaas@google.com, kwilczynski@kernel.org,
lpieralisi@kernel.org, mani@kernel.org, robh@kernel.org,
arnd@arndb.de, jgg@ziepe.ca, jacob.pan@linux.microsoft.com,
tgopinath@linux.microsoft.com,
easwar.hariharan@linux.microsoft.com, mrathor@linux.microsoft.com
In-Reply-To: <SN6PR02MB41575E067DFEBEACF316CD35D4FA2@SN6PR02MB4157.namprd02.prod.outlook.com>
On Mon, Jul 13, 2026 at 05:37:51PM +0000, Michael Kelley wrote:
> From: Yu Zhang <zhangyu1@linux.microsoft.com> Sent: Monday, July 13, 2026 9:46 AM
> >
> > On Sat, Jul 11, 2026 at 06:31:15PM +0000, Michael Kelley wrote:
> > > From: Yu Zhang <zhangyu1@linux.microsoft.com> Sent: Friday, July 10, 2026 12:34 AM
>
> [snip]
>
> > >
> > > One new thought: Have you considered the hibernate/resume
> > > cycle? Does anything need to be done with the pvIOMMU to
> > > make it functional again after resume? I see that the Intel and
> > > AMD IOMMU drivers have suspend and resume functions. I
> > > don't know enough about the Hyper-V pvIOMMU to know if it
> > > might also need suspend and resume functions.
> > >
> >
> > Thanks for raising this, Michael. We have not considered such support.
> >
> > My understanding is that the Intel and AMD drivers only disable the
> > IOMMU translation, flush the IOTLB during the suspend and re-enable/
> > reload the preserved root tables and other HW state during in the
> > resueme.
> >
> > But for pvIOMMU, I guess such job shall be done by the hypervisor?
> > For a device resumed on the same VM, its logical device ID should
> > also remain unchanged? And the corresponding Hyper-V domain objects,
> > configuration, and device attachments shall be preserved and restored
> > by hypervisor? I don't think the current Hyper-V ABI explicitly defines
> > this. But maybe if we want such feature, it could be done by the
> > hypervisor transparently?
> >
>
> I agree with your and Jacob's comments that the guest doesn't have
> any responsibility for saving/restoring IOMMU hardware state, as the
> Intel and AMD IOMMU drivers do.
>
> But yes, I'm wondering about the Hyper-V domain objects and device
> attachments. I doubt Hyper-V can do anything to save and restore
> them. Hibernation is a Linux concept that the Hyper-V host doesn't
> know anything about.
>
> Hibernation is already complicated, and in a VM it is even worse. :-(
> As a start, see Documentation/virt/hyperv/hibernation.rst, which I
> wrote about 18 months ago. It provides some basics as well as outlines
> the additional complexity in a Hyper-V guest VM. I'll also try to spend
> some time thinking through the implications for a pvIOMMU, and let
> you know if I have any more thoughts.
>
Thank you, Michael, and thanks for pointing us to the documentation. I
need some time to better understand the Linux guest hibernation and resume
flow and its implications for pvIOMMU.
Meanwhile, do you think this limitation should be documented in the
commit message or the cover letter?
B.R.
Yu
> Michael
^ permalink raw reply
* Re: [PATCH v8 5/8] drm/nouveau: Use hmm_range_fault_unlocked_timeout() for SVM faults
From: Andrew Morton @ 2026-07-13 23:18 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: airlied, akhilesh, corbet, dakr, david, decui, haiyangz, jgg,
kees, kys, leon, liam, lizhi.hou, ljs, longli, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
wei.liu, dri-devel, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <alUZZYIPY-UkhpY4@skinsburskii>
On Mon, 13 Jul 2026 09:59:17 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
> > > I'm not sure... The "timeout - jiffies" can become negative.
> > > Won't 1UL convert both of them to "UL" and thus make the comparison
> > > overflow?
> >
> > `timeout' and `jiffies' are both unsigned long.
>
> Yeah, I’m sorry for the sloppy wording.
>
> What I meant was: will "max(timeout - jiffies, 1UL)" correctly handle
> the case where jiffies < timeout?
That will return `timeout - jiffies': a smallish positive number.
I'm not sure what's intended here. Perhaps the code should be
using time_after() or similar?
^ permalink raw reply
* Re: [PATCH v8 0/8] mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings
From: Andrew Morton @ 2026-07-13 22:45 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: airlied, akhilesh, corbet, dakr, david, decui, haiyangz, jgg,
kees, kys, leon, liam, lizhi.hou, ljs, longli, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
wei.liu, dri-devel, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <alVRU38lMfvmUFqJ@skinsburskii>
On Mon, 13 Jul 2026 13:57:55 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
> > > I rebased this series on top of mm-new right before sending it out.
> > > Should I have used a different branch?
> >
> > mm-new is good - Sashiko attempts that. But it's changing rapidly at
> > this point in the development cycle.
> >
>
> I’d like to send another revision addressing a few comments and also
> replace the `max/max_t` check with something simpler.
>
> Which branch should I base it on so that Sashiko can apply it
> successfully?
mainline Linus would be safest.
> Or would it be better to send fixups against `mm-new`?
That should work as well, but it doesn't give us a Sashiko scan of the
whole patchset.
^ permalink raw reply
* Re: [PATCH v8 0/8] mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings
From: Stanislav Kinsburskii @ 2026-07-13 20:57 UTC (permalink / raw)
To: Andrew Morton
Cc: airlied, akhilesh, corbet, dakr, david, decui, haiyangz, jgg,
kees, kys, leon, liam, lizhi.hou, ljs, longli, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
wei.liu, dri-devel, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <20260710224950.53bcb43ce7e564f07a1f6a8c@linux-foundation.org>
On Fri, Jul 10, 2026 at 10:49:50PM -0700, Andrew Morton wrote:
> On Fri, 10 Jul 2026 20:22:33 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
>
> > On Fri, Jul 10, 2026 at 03:11:51PM -0700, Andrew Morton wrote:
> > > On Fri, 10 Jul 2026 14:26:20 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
> > >
> > > > This series extends the HMM framework to support userfaultfd-backed memory
> > > > by allowing the mmap read lock to be dropped during hmm_range_fault().
> > >
> > > Thanks. This seems fairly mature and mostly-reviewed so I'll give it a
> > > spin in mm.git's mm-new branch.
> > >
> > > Unfortunately Sashiko wasn't able to apply this or v7. I'm not sure
> > > what base you were using. Hopefully there's a reason for a v9 so we
> > > can retry this.
> > >
> >
> > I rebased this series on top of mm-new right before sending it out.
> > Should I have used a different branch?
>
> mm-new is good - Sashiko attempts that. But it's changing rapidly at
> this point in the development cycle.
>
I’d like to send another revision addressing a few comments and also
replace the `max/max_t` check with something simpler.
Which branch should I base it on so that Sashiko can apply it
successfully?
Or would it be better to send fixups against `mm-new`?
Thanks, Stanislav
^ permalink raw reply
* RE: [PATCH v2 3/4] iommu/hyperv: Add para-virtualized IOMMU support for Hyper-V guest
From: Michael Kelley @ 2026-07-13 17:37 UTC (permalink / raw)
To: Yu Zhang
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
iommu@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arch@vger.kernel.org, wei.liu@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, decui@microsoft.com, longli@microsoft.com,
joro@8bytes.org, will@kernel.org, robin.murphy@arm.com,
bhelgaas@google.com, kwilczynski@kernel.org,
lpieralisi@kernel.org, mani@kernel.org, robh@kernel.org,
arnd@arndb.de, jgg@ziepe.ca, jacob.pan@linux.microsoft.com,
tgopinath@linux.microsoft.com,
easwar.hariharan@linux.microsoft.com, mrathor@linux.microsoft.com
In-Reply-To: <3ty6yq6oftsvq52skrngjv5xpyixhsyfo3dndhoujt7emxsb2o@y6ischifpmfn>
From: Yu Zhang <zhangyu1@linux.microsoft.com> Sent: Monday, July 13, 2026 9:46 AM
>
> On Sat, Jul 11, 2026 at 06:31:15PM +0000, Michael Kelley wrote:
> > From: Yu Zhang <zhangyu1@linux.microsoft.com> Sent: Friday, July 10, 2026 12:34 AM
[snip]
> >
> > One new thought: Have you considered the hibernate/resume
> > cycle? Does anything need to be done with the pvIOMMU to
> > make it functional again after resume? I see that the Intel and
> > AMD IOMMU drivers have suspend and resume functions. I
> > don't know enough about the Hyper-V pvIOMMU to know if it
> > might also need suspend and resume functions.
> >
>
> Thanks for raising this, Michael. We have not considered such support.
>
> My understanding is that the Intel and AMD drivers only disable the
> IOMMU translation, flush the IOTLB during the suspend and re-enable/
> reload the preserved root tables and other HW state during in the
> resueme.
>
> But for pvIOMMU, I guess such job shall be done by the hypervisor?
> For a device resumed on the same VM, its logical device ID should
> also remain unchanged? And the corresponding Hyper-V domain objects,
> configuration, and device attachments shall be preserved and restored
> by hypervisor? I don't think the current Hyper-V ABI explicitly defines
> this. But maybe if we want such feature, it could be done by the
> hypervisor transparently?
>
I agree with your and Jacob's comments that the guest doesn't have
any responsibility for saving/restoring IOMMU hardware state, as the
Intel and AMD IOMMU drivers do.
But yes, I'm wondering about the Hyper-V domain objects and device
attachments. I doubt Hyper-V can do anything to save and restore
them. Hibernation is a Linux concept that the Hyper-V host doesn't
know anything about.
Hibernation is already complicated, and in a VM it is even worse. :-(
As a start, see Documentation/virt/hyperv/hibernation.rst, which I
wrote about 18 months ago. It provides some basics as well as outlines
the additional complexity in a Hyper-V guest VM. I'll also try to spend
some time thinking through the implications for a pvIOMMU, and let
you know if I have any more thoughts.
Michael
^ permalink raw reply
* Re: [PATCH v8 8/8] drm/gpusvm: Use hmm_range_fault_unlocked_timeout() for range faults
From: Stanislav Kinsburskii @ 2026-07-13 17:01 UTC (permalink / raw)
To: Matthew Brost
Cc: airlied, akhilesh, akpm, corbet, dakr, david, decui, haiyangz,
jgg, kees, kys, leon, liam, lizhi.hou, ljs, longli, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
wei.liu, dri-devel, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <alUSq0o7CC2Pnr+H@gsse-cloud1.jf.intel.com>
On Mon, Jul 13, 2026 at 09:30:35AM -0700, Matthew Brost wrote:
> On Fri, Jul 10, 2026 at 02:27:19PM -0700, Stanislav Kinsburskii wrote:
>
> Please send series like this to intel-xe@lists.freedesktop.org list too
> as this will trigger our CI which expercises the change paths changed in
> this series.
>
> > Several GPU SVM paths take mmap_read_lock() only to call hmm_range_fault(),
> > then retry -EBUSY until HMM_RANGE_DEFAULT_TIMEOUT expires. Those paths use
> > MMU interval notifiers whose mm matches the mm that was locked for the HMM
> > fault.
> >
> > Use hmm_range_fault_unlocked_timeout() for those faults and pass the
> > remaining retry budget to HMM. The helper owns mmap_lock acquisition and
> > refreshes range->notifier_seq internally for each retry, while GPU SVM
> > keeps its existing driver-lock validation with mmu_interval_read_retry()
> > after a successful fault.
> >
> > Leave drm_gpusvm_check_pages() on hmm_range_fault() because that path is
> > called with the mmap lock already held by its caller.
> >
> > Signed-off-by: Stanislav Kinsburskii <skinsburskii@gmail.com>
> > Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> > ---
> > drivers/gpu/drm/drm_gpusvm.c | 52 ++++++------------------------------------
> > 1 file changed, 7 insertions(+), 45 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gpusvm.c b/drivers/gpu/drm/drm_gpusvm.c
> > index 958cb605aedd..6b7a6eaebcd9 100644
> > --- a/drivers/gpu/drm/drm_gpusvm.c
> > +++ b/drivers/gpu/drm/drm_gpusvm.c
> > @@ -788,22 +788,8 @@ enum drm_gpusvm_scan_result drm_gpusvm_scan_mm(struct drm_gpusvm_range *range,
> > hmm_range.hmm_pfns = pfns;
> >
> > retry:
> > - hmm_range.notifier_seq = mmu_interval_read_begin(notifier);
> > - mmap_read_lock(range->gpusvm->mm);
> > -
> > - while (true) {
> > - err = hmm_range_fault(&hmm_range);
> > - if (err == -EBUSY) {
> > - if (time_after(jiffies, timeout))
> > - break;
> > -
> > - hmm_range.notifier_seq =
> > - mmu_interval_read_begin(notifier);
> > - continue;
> > - }
> > - break;
> > - }
> > - mmap_read_unlock(range->gpusvm->mm);
> > + err = hmm_range_fault_unlocked_timeout(&hmm_range,
> > + max(timeout - jiffies, 1L));
> > if (err)
> > goto err_free;
> >
> > @@ -1439,21 +1425,8 @@ int drm_gpusvm_get_pages(struct drm_gpusvm *gpusvm,
> > }
> >
> > hmm_range.hmm_pfns = pfns;
> > - while (true) {
> > - mmap_read_lock(mm);
> > - err = hmm_range_fault(&hmm_range);
> > - mmap_read_unlock(mm);
> > -
> > - if (err == -EBUSY) {
> > - if (time_after(jiffies, timeout))
> > - break;
> > -
> > - hmm_range.notifier_seq =
> > - mmu_interval_read_begin(notifier);
> > - continue;
> > - }
> > - break;
> > - }
> > + err = hmm_range_fault_unlocked_timeout(&hmm_range,
> > + max_t(long, timeout - jiffies, 1));
>
> Unaligned indentation.
>
> So I'd write this like this to avoid weird wraps:
>
> ctimeout = max_t(long, timeout - jiffies, 1));
> err = hmm_range_fault_unlocked_timeout(&hmm_range, ctimeout);
>
> > mmput(mm);
> > if (err)
> > goto err_free;
> > @@ -1736,24 +1709,13 @@ int drm_gpusvm_range_evict(struct drm_gpusvm *gpusvm,
> > return -ENOMEM;
> >
> > hmm_range.hmm_pfns = pfns;
> > - while (!time_after(jiffies, timeout)) {
> > - hmm_range.notifier_seq = mmu_interval_read_begin(notifier);
> > - if (time_after(jiffies, timeout)) {
> > - err = -ETIME;
> > - break;
> > - }
> > -
> > - mmap_read_lock(mm);
> > - err = hmm_range_fault(&hmm_range);
> > - mmap_read_unlock(mm);
> > - if (err != -EBUSY)
> > - break;
> > - }
> > + err = hmm_range_fault_unlocked_timeout(&hmm_range,
> > + max_t(long, timeout - jiffies, 1));
> >
>
> Same here.
>
> Nits, aside LGTM.
>
Will change as requested and send to intel-xe@lists.freedesktop.org next time.
Thanks,
Stanislav
> Matt
>
> > kvfree(pfns);
> > mmput(mm);
> >
> > - return err;
> > + return err == -EBUSY ? -ETIME : err;
> > }
> > EXPORT_SYMBOL_GPL(drm_gpusvm_range_evict);
> >
> >
> >
^ permalink raw reply
* Re: [PATCH v8 5/8] drm/nouveau: Use hmm_range_fault_unlocked_timeout() for SVM faults
From: Stanislav Kinsburskii @ 2026-07-13 16:59 UTC (permalink / raw)
To: Andrew Morton
Cc: airlied, akhilesh, corbet, dakr, david, decui, haiyangz, jgg,
kees, kys, leon, liam, lizhi.hou, ljs, longli, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
wei.liu, dri-devel, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <20260710224833.9caf2a0a9906f0515e326a45@linux-foundation.org>
On Fri, Jul 10, 2026 at 10:48:33PM -0700, Andrew Morton wrote:
> On Fri, 10 Jul 2026 20:16:35 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
>
> > On Fri, Jul 10, 2026 at 03:12:22PM -0700, Andrew Morton wrote:
> > > On Fri, 10 Jul 2026 14:26:58 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
> > >
> > > > @@ -683,15 +683,11 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
> > > > goto out;
> > > > }
> > > >
> > > > - range.notifier_seq = mmu_interval_read_begin(range.notifier);
> > > > - mmap_read_lock(mm);
> > > > - ret = hmm_range_fault(&range);
> > > > - mmap_read_unlock(mm);
> > > > - if (ret) {
> > > > - if (ret == -EBUSY)
> > > > - continue;
> > > > + ret = hmm_range_fault_unlocked_timeout(&range,
> > > > + max(timeout - jiffies,
> > > > + 1L));
> > >
> > > "1UL" here? I'd have expected min() to warn, as it likes to do.
> >
> > I'm not sure... The "timeout - jiffies" can become negative.
> > Won't 1UL convert both of them to "UL" and thus make the comparison
> > overflow?
>
> `timeout' and `jiffies' are both unsigned long.
Yeah, I’m sorry for the sloppy wording.
What I meant was: will "max(timeout - jiffies, 1UL)" correctly handle
the case where jiffies < timeout?
Thanks,
Stanislav
^ permalink raw reply
* Re: [PATCH v8 4/8] mshv: Use hmm_range_fault_unlocked_timeout() for region faults
From: Stanislav Kinsburskii @ 2026-07-13 16:56 UTC (permalink / raw)
To: Andrew Morton
Cc: airlied, akhilesh, corbet, dakr, david, decui, haiyangz, jgg,
kees, kys, leon, liam, lizhi.hou, ljs, longli, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
wei.liu, dri-devel, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <20260710224606.69235ab5c49b5987fd33e924@linux-foundation.org>
On Fri, Jul 10, 2026 at 10:46:06PM -0700, Andrew Morton wrote:
> On Fri, 10 Jul 2026 20:14:47 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
>
> > > > + mutex_lock(®ion->mreg_mutex);
> > > > +
> > > > + if (mmu_interval_read_retry(range.notifier, range.notifier_seq)) {
> > > > + mutex_unlock(®ion->mreg_mutex);
> > > > + cond_resched();
> > > > + goto again;
> > > > + }
> > > > +
> > >
> > > If the calling process has realtime scheduling policy and either a)
> > > we're uniprocessor or b) this process and the holder of
> > > interval_sub->invalidate_seq are both pinned to the same CPU then
> > > cond_resched() won't do anything, and this might be an infinite loop?
> >
> > Yes, looks like it might.
> > What can be done to prevent this?
>
> Well the best way is remove the polling loop and use a proper sleep/wakeup
> mechanism - mutex_lock()/prepare_to_wait()/etc.
>
> If the polling loop is to be retained then maybe msleep(1) or
> usleep_range()?
Well, running MSHV - or, I suppose, any other VM - on a uniprocessor host
would not be very efficient.
I’m not sure whether this corner case needs to be handled explicitly.
But even if it does, supporting or explicitly forbidding it would be a
separate change. As Jason noted, this is not a regression introduced by
this series.
Thanks,
Stanislav
^ permalink raw reply
* Re: [PATCH v2 3/4] iommu/hyperv: Add para-virtualized IOMMU support for Hyper-V guest
From: Yu Zhang @ 2026-07-13 16:46 UTC (permalink / raw)
To: Michael Kelley
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
iommu@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arch@vger.kernel.org, wei.liu@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, decui@microsoft.com, longli@microsoft.com,
joro@8bytes.org, will@kernel.org, robin.murphy@arm.com,
bhelgaas@google.com, kwilczynski@kernel.org,
lpieralisi@kernel.org, mani@kernel.org, robh@kernel.org,
arnd@arndb.de, jgg@ziepe.ca, jacob.pan@linux.microsoft.com,
tgopinath@linux.microsoft.com,
easwar.hariharan@linux.microsoft.com, mrathor@linux.microsoft.com
In-Reply-To: <SN6PR02MB4157805F23ACA85A668FA065D4FC2@SN6PR02MB4157.namprd02.prod.outlook.com>
On Sat, Jul 11, 2026 at 06:31:15PM +0000, Michael Kelley wrote:
> From: Yu Zhang <zhangyu1@linux.microsoft.com> Sent: Friday, July 10, 2026 12:34 AM
> >
> > On Thu, Jul 09, 2026 at 07:08:26PM +0000, Michael Kelley wrote:
> > > From: Yu Zhang <zhangyu1@linux.microsoft.com> Sent: Thursday, July 2, 2026 9:05 AM
> > > >
> > > > Add a para-virtualized IOMMU driver for Linux guests running on Hyper-V.
> > > > This driver implements stage-1 IO translation within the guest OS.
> > > > It integrates with the Linux IOMMU core, utilizing Hyper-V hypercalls
> > > > for:
> > > > - Capability discovery
> > > > - Domain allocation, configuration, and deallocation
> > > > - Device attachment and detachment
> > > > - IOTLB invalidation
> > > >
> > > > The driver constructs x86-compatible stage-1 IO page tables in the
> > > > guest memory using consolidated IO page table helpers. This allows
> > > > the guest to manage stage-1 translations independently of vendor-
> > > > specific drivers (like Intel VT-d or AMD IOMMU).
> > > >
> > > > Hyper-V consumes this stage-1 IO page table when a device domain is
> > > > created and configured, and nests it with the host's stage-2 IO page
> > > > tables, therefore eliminating the VM exits for guest IOMMU mapping
> > > > operations. For unmapping operations, VM exits to perform the IOTLB
> > > > flush are still unavoidable.
> > > >
> > > > To identify a device in its hypercall interface, the driver looks up the
> > > > logical device ID prefix registered for the device's PCI domain (see the
> > > > logical device ID registry in hv_common.c) and combines it with the PCI
> > > > function number of the endpoint device.
> > > >
> > > > Co-developed-by: Wei Liu <wei.liu@kernel.org>
> > > > Signed-off-by: Wei Liu <wei.liu@kernel.org>
> > > > Co-developed-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
> > > > Signed-off-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
> > > > Signed-off-by: Yu Zhang <zhangyu1@linux.microsoft.com>
> > > > ---
> > > > arch/x86/hyperv/hv_init.c | 4 +
> > > > arch/x86/include/asm/mshyperv.h | 4 +
> > > > drivers/iommu/Kconfig | 1 +
> > > > drivers/iommu/hyperv/Kconfig | 16 +
> > > > drivers/iommu/hyperv/Makefile | 1 +
> > > > drivers/iommu/hyperv/iommu.c | 620 ++++++++++++++++++++++++++++++++
> > > > drivers/iommu/hyperv/iommu.h | 51 +++
> > > > 7 files changed, 697 insertions(+)
> > > > create mode 100644 drivers/iommu/hyperv/Kconfig
> > > > create mode 100644 drivers/iommu/hyperv/iommu.c
> > > > create mode 100644 drivers/iommu/hyperv/iommu.h
> > > >
> > > > diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> > > > index 55a8b6de2865..094f9f7ddb72 100644
> > > > --- a/arch/x86/hyperv/hv_init.c
> > > > +++ b/arch/x86/hyperv/hv_init.c
> > > > @@ -578,6 +578,10 @@ void __init hyperv_init(void)
> > > > old_setup_percpu_clockev = x86_init.timers.setup_percpu_clockev;
> > > > x86_init.timers.setup_percpu_clockev = hv_stimer_setup_percpu_clockev;
> > > >
> > > > +#ifdef CONFIG_HYPERV_PVIOMMU
> > > > + x86_init.iommu.iommu_init = hv_iommu_init;
> > > > +#endif
> > > > +
> > >
> > > This approach to .iommu_init is a bit different from the Intel VT-d and
> > > AMD IOMMU initialization. Those cases detect the existence of the
> > > IOMMU first via a "detect" function that is called in pci_iommu_alloc().
> > > If the detect function finds an IOMMU, it sets .iommu_init. Any
> > > reason not to use the same approach for the Hyper-V pvIOMMU?
> > > One problem with exactly the same approach is that Hyper-V
> > > hypercalls aren't set up at the time pci_iommu_alloc() runs.
> >
> > Yes. That's why I did not follow Intel VT-d and AMD IOMMU's approach -
> > the hv_hypercall_pg is not ready yet.
> >
> > > So you'd have to call the "detect" function here in hyperv_init(),
> > > and have the detect function set .iommu_init if pvIOMMU
> > > support is present.
> > >
> >
> > The detecion of the presense and capabilities of the pvIOMMU are done
> > in one hypercall. But I guess we can:
> > - do the HVCALL_GET_IOMMU_CAPABILITIES in hyperv_init();
> > - check the presense and only set .iommu_init to hyperv_iommu_init()
> > if pvIOMMU is present;
> > - and then do other capalibities check in hv_iommu_init();
> > - only give the error log if an pvIOMMU is present yet its capabilities
> > are not legal.
> > So below errors will not be printed for guest kernels built with
> > CONFIG_HYPERV_PVIOMMU and running on a host w/o one.
>
> I see your point about detection and capabilities coming from
> single hypercall, and that separating those two functions
> would duplicate code. My biggest concern is about errors in the
> dmesg log for a valid configuration where the host doesn't
> supply a pvIOMMU. Fixing that problem in the context of the
> current code structure would be acceptable.
>
> A minor concern is arguably misusing the .iommu_init function
> to do detection. But that function is only called once at boot
> time, so leaving it set to hv_iommu_init() even if there isn't
> a Hyper-V pvIOMMU is probably more a conceptual issue
> than a real issue. I wouldn't object if you prefer to leave that
> "as is" to avoid duplicating the hypercall.
>
> One new thought: Have you considered the hibernate/resume
> cycle? Does anything need to be done with the pvIOMMU to
> make it functional again after resume? I see that the Intel and
> AMD IOMMU drivers have suspend and resume functions. I
> don't know enough about the Hyper-V pvIOMMU to know if it
> might also need suspend and resume functions.
>
Thanks for raising this, Michael. We have not considered such support.
My understanding is that the Intel and AMD drivers only disable the
IOMMU translation, flush the IOTLB during the suspend and re-enable/
reload the preserved root tables and other HW state during in the
resueme.
But for pvIOMMU, I guess such job shall be done by the hypervisor?
For a device resumed on the same VM, its logical device ID should
also remain unchanged? And the corresponding Hyper-V domain objects,
configuration, and device attachments shall be preserved and restored
by hypervisor? I don't think the current Hyper-V ABI explicitly defines
this. But maybe if we want such feature, it could be done by the
hypervisor transparently?
B.R.
Yu
> Michael
>
> >
> > > While the code currently in this patch works, it generates boot
> > > time errors if the kernel is built with CONFIG_HYPERV_PVIOMMU
> > > but run in a guest on a host without pvIOMMU support:
> > >
> > > [ 0.101673] Hyper-V pvIOMMU: HVCALL_GET_IOMMU_CAPABILITIES failed, status 2
> > > [ 0.101675] Hyper-V pvIOMMU: HVCALL_GET_IOMMU_CAPABILITIES failed: -22
> > >
> > > We really don't want errors if it's just the case that there's no
> > > pvIOMMU support. A less alarming message (at INFO level instead
> > > of ERROR level) about running without an IOMMU might be OK, but
> > > perhaps is unnecessary since you have an INFO message if the
> > > pvIOMMU is found and successfully initialized.
> > >
>
^ permalink raw reply
* Re: [PATCH v8 8/8] drm/gpusvm: Use hmm_range_fault_unlocked_timeout() for range faults
From: Matthew Brost @ 2026-07-13 16:30 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: airlied, akhilesh, akpm, corbet, dakr, david, decui, haiyangz,
jgg, kees, kys, leon, liam, lizhi.hou, ljs, longli, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
wei.liu, dri-devel, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <178371883977.900500.2198446134676328631.stgit@skinsburskii>
On Fri, Jul 10, 2026 at 02:27:19PM -0700, Stanislav Kinsburskii wrote:
Please send series like this to intel-xe@lists.freedesktop.org list too
as this will trigger our CI which expercises the change paths changed in
this series.
> Several GPU SVM paths take mmap_read_lock() only to call hmm_range_fault(),
> then retry -EBUSY until HMM_RANGE_DEFAULT_TIMEOUT expires. Those paths use
> MMU interval notifiers whose mm matches the mm that was locked for the HMM
> fault.
>
> Use hmm_range_fault_unlocked_timeout() for those faults and pass the
> remaining retry budget to HMM. The helper owns mmap_lock acquisition and
> refreshes range->notifier_seq internally for each retry, while GPU SVM
> keeps its existing driver-lock validation with mmu_interval_read_retry()
> after a successful fault.
>
> Leave drm_gpusvm_check_pages() on hmm_range_fault() because that path is
> called with the mmap lock already held by its caller.
>
> Signed-off-by: Stanislav Kinsburskii <skinsburskii@gmail.com>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/gpu/drm/drm_gpusvm.c | 52 ++++++------------------------------------
> 1 file changed, 7 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gpusvm.c b/drivers/gpu/drm/drm_gpusvm.c
> index 958cb605aedd..6b7a6eaebcd9 100644
> --- a/drivers/gpu/drm/drm_gpusvm.c
> +++ b/drivers/gpu/drm/drm_gpusvm.c
> @@ -788,22 +788,8 @@ enum drm_gpusvm_scan_result drm_gpusvm_scan_mm(struct drm_gpusvm_range *range,
> hmm_range.hmm_pfns = pfns;
>
> retry:
> - hmm_range.notifier_seq = mmu_interval_read_begin(notifier);
> - mmap_read_lock(range->gpusvm->mm);
> -
> - while (true) {
> - err = hmm_range_fault(&hmm_range);
> - if (err == -EBUSY) {
> - if (time_after(jiffies, timeout))
> - break;
> -
> - hmm_range.notifier_seq =
> - mmu_interval_read_begin(notifier);
> - continue;
> - }
> - break;
> - }
> - mmap_read_unlock(range->gpusvm->mm);
> + err = hmm_range_fault_unlocked_timeout(&hmm_range,
> + max(timeout - jiffies, 1L));
> if (err)
> goto err_free;
>
> @@ -1439,21 +1425,8 @@ int drm_gpusvm_get_pages(struct drm_gpusvm *gpusvm,
> }
>
> hmm_range.hmm_pfns = pfns;
> - while (true) {
> - mmap_read_lock(mm);
> - err = hmm_range_fault(&hmm_range);
> - mmap_read_unlock(mm);
> -
> - if (err == -EBUSY) {
> - if (time_after(jiffies, timeout))
> - break;
> -
> - hmm_range.notifier_seq =
> - mmu_interval_read_begin(notifier);
> - continue;
> - }
> - break;
> - }
> + err = hmm_range_fault_unlocked_timeout(&hmm_range,
> + max_t(long, timeout - jiffies, 1));
Unaligned indentation.
So I'd write this like this to avoid weird wraps:
ctimeout = max_t(long, timeout - jiffies, 1));
err = hmm_range_fault_unlocked_timeout(&hmm_range, ctimeout);
> mmput(mm);
> if (err)
> goto err_free;
> @@ -1736,24 +1709,13 @@ int drm_gpusvm_range_evict(struct drm_gpusvm *gpusvm,
> return -ENOMEM;
>
> hmm_range.hmm_pfns = pfns;
> - while (!time_after(jiffies, timeout)) {
> - hmm_range.notifier_seq = mmu_interval_read_begin(notifier);
> - if (time_after(jiffies, timeout)) {
> - err = -ETIME;
> - break;
> - }
> -
> - mmap_read_lock(mm);
> - err = hmm_range_fault(&hmm_range);
> - mmap_read_unlock(mm);
> - if (err != -EBUSY)
> - break;
> - }
> + err = hmm_range_fault_unlocked_timeout(&hmm_range,
> + max_t(long, timeout - jiffies, 1));
>
Same here.
Nits, aside LGTM.
Matt
> kvfree(pfns);
> mmput(mm);
>
> - return err;
> + return err == -EBUSY ? -ETIME : err;
> }
> EXPORT_SYMBOL_GPL(drm_gpusvm_range_evict);
>
>
>
^ permalink raw reply
* Re: [PATCH v2 3/4] iommu/hyperv: Add para-virtualized IOMMU support for Hyper-V guest
From: Jacob Pan @ 2026-07-13 16:13 UTC (permalink / raw)
To: Michael Kelley
Cc: Yu Zhang, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org, iommu@lists.linux.dev,
linux-pci@vger.kernel.org, linux-arch@vger.kernel.org,
wei.liu@kernel.org, kys@microsoft.com, haiyangz@microsoft.com,
decui@microsoft.com, longli@microsoft.com, joro@8bytes.org,
will@kernel.org, robin.murphy@arm.com, bhelgaas@google.com,
kwilczynski@kernel.org, lpieralisi@kernel.org, mani@kernel.org,
robh@kernel.org, arnd@arndb.de, jgg@ziepe.ca,
tgopinath@linux.microsoft.com,
easwar.hariharan@linux.microsoft.com, mrathor@linux.microsoft.com,
jacob.pan
In-Reply-To: <SN6PR02MB4157805F23ACA85A668FA065D4FC2@SN6PR02MB4157.namprd02.prod.outlook.com>
Hi Michael,
On Sat, 11 Jul 2026 18:31:15 +0000
Michael Kelley <mhklinux@outlook.com> wrote:
> One new thought: Have you considered the hibernate/resume
> cycle? Does anything need to be done with the pvIOMMU to
> make it functional again after resume? I see that the Intel and
> AMD IOMMU drivers have suspend and resume functions. I
> don't know enough about the Hyper-V pvIOMMU to know if it
> might also need suspend and resume functions.
I don't think the Hyper-V pvIOMMU guest driver needs the same kind of
suspend/resume handling as a hardware IOMMU driver. Unlike VT-d or AMD
IOMMU, the guest driver does not own physical IOMMU registers, root
tables, command queues, or translation enable state that must be saved
and reprogrammed on resume.
For nested translation, the guest does own the stage-1 I/O page tables,
but those are normal guest memory. They survive S3 as system RAM. The
guest driver still needs to issue the normal pvIOMMU invalidations when
it changes S1 mappings, but suspend/resume by itself does not modify
the S1 page tables and should not require a special flush.
The important contract is on the Hyper-V side: Hyper-V owns translation
enable/disable and must prevent device DMA while translation state is
not valid.
Thanks,
Jacob
^ permalink raw reply
* Re: [PATCH rdma-next 1/2] RDMA/bnxt_re: Validate udata before destroying resources
From: Leon Romanovsky @ 2026-07-13 14:56 UTC (permalink / raw)
To: Jacob Moroni
Cc: Selvin Xavier, Kalesh AP, Jason Gunthorpe, Michael Margolin,
Gal Pressman, Yossi Leybovich, Cheng Xu, Kai Shen,
Chengchang Tang, Junxian Huang, Tatyana Nikolova, Long Li,
Konstantin Taranov, Yishai Hadas, Michal Kalderon, Nelson Escobar,
Satish Kharat, Bernard Metzler, linux-rdma, linux-kernel,
linux-hyperv
In-Reply-To: <CAHYDg1S5jpZY=CRmbcH8MYHzyV4ro4MdzJ2gAj2fhaFfQo-yXA@mail.gmail.com>
On Mon, Jul 13, 2026 at 10:21:49AM -0400, Jacob Moroni wrote:
> These changes look good but there is also a call to ib_respond_empty_udata
> in bnxt_re_resize_cq (but that method does take input data).
>
> Is that one a problem? I guess the resize could complete but the upper
> layers would think it failed if the ib_respond_empty_udata call fails?
I think that modify verbs should be fixed too.
>
> Reviewed-by: Jacob Moroni <jmoroni@google.com>
Thanks
^ permalink raw reply
* Re: [PATCH v8 4/8] mshv: Use hmm_range_fault_unlocked_timeout() for region faults
From: Jason Gunthorpe @ 2026-07-13 14:55 UTC (permalink / raw)
To: Andrew Morton
Cc: Stanislav Kinsburskii, airlied, akhilesh, corbet, dakr, david,
decui, haiyangz, kees, kys, leon, liam, lizhi.hou, ljs, longli,
lyude, maarten.lankhorst, mamin506, mhocko, mripard, nouveau,
ogabbay, oleg, rppt, shuah, simona, skhan, surenb, tzimmermann,
vbabka, wei.liu, dri-devel, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <20260710151216.0397a6f9ac5c7b4ccd274cc1@linux-foundation.org>
On Fri, Jul 10, 2026 at 03:12:16PM -0700, Andrew Morton wrote:
> > + mutex_lock(®ion->mreg_mutex);
> > +
> > + if (mmu_interval_read_retry(range.notifier, range.notifier_seq)) {
> > + mutex_unlock(®ion->mreg_mutex);
> > + cond_resched();
> > + goto again;
> > + }
> > +
>
> If the calling process has realtime scheduling policy and either a)
> we're uniprocessor or b) this process and the holder of
> interval_sub->invalidate_seq are both pinned to the same CPU then
> cond_resched() won't do anything, and this might be an infinite loop?
I think hmm and kvm have had this issue for a long time? I don't see
anything in the mmu notifier locking scheme that would alleviate it at
least
So.. In terms of this series I'd leave it, it is no worse than before?
Jason
^ permalink raw reply
* Re: [PATCH rdma-next 1/2] RDMA/bnxt_re: Validate udata before destroying resources
From: Jacob Moroni @ 2026-07-13 14:21 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Selvin Xavier, Kalesh AP, Jason Gunthorpe, Michael Margolin,
Gal Pressman, Yossi Leybovich, Cheng Xu, Kai Shen,
Chengchang Tang, Junxian Huang, Tatyana Nikolova, Long Li,
Konstantin Taranov, Yishai Hadas, Michal Kalderon, Nelson Escobar,
Satish Kharat, Bernard Metzler, linux-rdma, linux-kernel,
linux-hyperv
In-Reply-To: <20260713-fix-destroy-no-udata-v1-1-fcca2e34fd57@nvidia.com>
These changes look good but there is also a call to ib_respond_empty_udata
in bnxt_re_resize_cq (but that method does take input data).
Is that one a problem? I guess the resize could complete but the upper
layers would think it failed if the ib_respond_empty_udata call fails?
Reviewed-by: Jacob Moroni <jmoroni@google.com>
^ permalink raw reply
* Re: [PATCH rdma-next 1/2] RDMA/bnxt_re: Validate udata before destroying resources
From: sashiko-bot @ 2026-07-13 8:28 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: linux-hyperv
In-Reply-To: <20260713-fix-destroy-no-udata-v1-1-fcca2e34fd57@nvidia.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Missing hash_del on error paths in CQ and SRQ creation leads to hash table corruption and use-after-free.
- [Critical] Lockless modifications and iterations over device-global hash tables (cq_hash and srq_hash) risk linked-list corruption.
- [High] Hardware Address Handle (AH) resource leak in bnxt_re_create_ah on udata response failure.
- [High] Hardware and driver state modification applied before udata validation in modify/resize callbacks.
- [High] Memory leak of rdma_user_mmap_entry in bnxt_re_alloc_ucontext if udata validation or response fails.
--
--- Patch [1]: [PATCH rdma-next 1/2] RDMA/bnxt_re: Validate udata before destroying resources ---
commit 1661d6c7bf0fdc123a46584fd78311e626482940
Author: Leon Romanovsky <leon@kernel.org>
RDMA/bnxt_re: Validate udata before destroying resources
This commit modifies the destroy callbacks to validate user data earlier
using ib_no_udata_io() before resources are torn down. This prevents
userspace access failures from leaving the driver and hardware in an
inconsistent state.
> diff --git a/drivers/infiniband/hw/bnxt_re/ib_verbs.c b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> index 5657625290076..ef9943be18861 100644
> --- a/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> +++ b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
[ ... ]
> @@ -3471,7 +3471,7 @@ int bnxt_re_destroy_cq(struct ib_cq *ib_cq, struct ib_udata *udata)
> nq = cq->qplib_cq.nq;
> cctx = rdev->chip_ctx;
>
> - ret = ib_is_udata_in_empty(udata);
> + ret = ib_no_udata_io(udata);
> if (ret)
> return ret;
[Severity: Critical]
This is a pre-existing issue, but does removing the CQ from the global hash
table here require locking?
In bnxt_re_destroy_cq(), just after this udata validation, the CQ is deleted
from rdev->cq_hash via hash_del() without any locks:
if (cctx->modes.toggle_bits & BNXT_QPLIB_CQ_TOGGLE_BIT)
hash_del(&cq->hash_entry);
However, concurrent additions occur in bnxt_re_create_user_cq() via
hash_add() and lockless iterations happen in bnxt_re_search_for_cq(). Can
this cause list corruption or use-after-free if multiple threads create,
destroy, or query CQs concurrently?
[Severity: Critical]
This isn't a bug introduced by this patch, but can this leak a dangling
pointer into the hash table on error?
In bnxt_re_create_user_cq(), if memory allocation for the page fails or
ib_respond_udata() fails, we jump to the error path and free the CQ without
removing it from the hash table:
bnxt_re_create_user_cq() {
...
if (cctx->modes.toggle_bits & BNXT_QPLIB_CQ_TOGGLE_BIT) {
hash_add(rdev->cq_hash, &cq->hash_entry, cq->qplib_cq.id);
/* Allocate a page */
cq->uctx_cq_page = (void *)get_zeroed_page(GFP_KERNEL);
if (!cq->uctx_cq_page) {
rc = -ENOMEM;
goto destroy_cq;
}
...
rc = ib_respond_udata(udata, resp);
if (rc)
goto free_mem;
...
free_mem:
free_page((unsigned long)cq->uctx_cq_page);
destroy_cq:
bnxt_qplib_destroy_cq(&rdev->qplib_res, &cq->qplib_cq);
free_umem:
ib_umem_release(cq->umem);
return rc;
}
Since hash_del() isn't called here, could subsequent lookups hit a
use-after-free? This same pattern also appears in bnxt_re_create_srq()
where srq_hash is modified.
[Severity: High]
This isn't a bug introduced by this patch, but since this patch fixes udata
validation in destroy callbacks, should similar fixes be applied to the
modify and resize callbacks?
In functions like bnxt_re_modify_srq(), bnxt_re_modify_qp(), and
bnxt_re_resize_cq(), the hardware and driver state is modified before the
final copy-to-user response:
drivers/infiniband/hw/bnxt_re/ib_verbs.c:bnxt_re_modify_qp() {
...
/* hardware QP state is modified here */
...
return ib_respond_empty_udata(udata);
}
If the udata response buffer is invalid, the function fails, but the hardware
and driver states are already updated. Can this desynchronize kernel state
from userspace state?
[Severity: High]
This is a pre-existing issue, but does this error path permanently leak the
hardware Address Handle?
If ib_respond_empty_udata() fails in bnxt_re_create_ah(), the function
returns the error directly without cleaning up the hardware AH or
decrementing ah_count:
drivers/infiniband/hw/bnxt_re/ib_verbs.c:bnxt_re_create_ah() {
...
return ib_respond_empty_udata(udata);
}
Can an unprivileged application repeatedly trigger this by passing an invalid
udata response buffer to exhaust hardware resources and kernel memory?
[Severity: High]
This is a pre-existing issue, but does the cfail error path leak the mmap
entry?
In bnxt_re_alloc_ucontext(), if validation or the udata response fails, we
jump to cfail:
drivers/infiniband/hw/bnxt_re/ib_verbs.c:bnxt_re_alloc_ucontext() {
...
rc = ib_respond_udata(udata, resp);
if (rc) {
rc = -EFAULT;
goto cfail;
}
...
cfail:
free_page((unsigned long)uctx->shpg);
uctx->shpg = NULL;
fail:
return rc;
}
This path skips calling rdma_user_mmap_entry_remove(uctx->shpage_mmap).
Does this permanently leak the kzalloc'd mmap entry, allowing memory
exhaustion if triggered repeatedly by userspace?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260713-fix-destroy-no-udata-v1-0-fcca2e34fd57@nvidia.com?part=1
^ permalink raw reply
* [PATCH rdma-next 2/2] RDMA: Remove redundant memset() from query_device callbacks
From: Leon Romanovsky @ 2026-07-13 8:10 UTC (permalink / raw)
To: Selvin Xavier, Kalesh AP, Jason Gunthorpe, Leon Romanovsky,
Michael Margolin, Gal Pressman, Yossi Leybovich, Cheng Xu,
Kai Shen, Chengchang Tang, Junxian Huang, Tatyana Nikolova,
Long Li, Konstantin Taranov, Yishai Hadas, Michal Kalderon,
Nelson Escobar, Satish Kharat, Bernard Metzler
Cc: linux-rdma, linux-kernel, linux-hyperv
In-Reply-To: <20260713-fix-destroy-no-udata-v1-0-fcca2e34fd57@nvidia.com>
From: Leon Romanovsky <leonro@nvidia.com>
The core always hands the driver's query_device() callback a zeroed
ib_device_attr. There are only two callers of the op and both clear the
structure before invoking it: setup_device() memsets &device->attrs, and
ib_uverbs_ex_query_device() passes an on-stack structure initialized to {}.
The open-coded memset(props, 0, sizeof(*props)) at the top of the driver
callbacks is therefore redundant. Remove it from all drivers.
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
drivers/infiniband/hw/bnxt_re/ib_verbs.c | 1 -
drivers/infiniband/hw/efa/efa_verbs.c | 1 -
drivers/infiniband/hw/erdma/erdma_verbs.c | 2 --
drivers/infiniband/hw/hns/hns_roce_main.c | 2 --
drivers/infiniband/hw/irdma/verbs.c | 1 -
drivers/infiniband/hw/mana/main.c | 1 -
drivers/infiniband/hw/mlx4/main.c | 2 --
drivers/infiniband/hw/mlx5/main.c | 1 -
drivers/infiniband/hw/mthca/mthca_provider.c | 2 --
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 1 -
drivers/infiniband/hw/qedr/verbs.c | 2 --
drivers/infiniband/hw/usnic/usnic_ib_verbs.c | 1 -
drivers/infiniband/sw/siw/siw_verbs.c | 2 --
13 files changed, 19 deletions(-)
diff --git a/drivers/infiniband/hw/bnxt_re/ib_verbs.c b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
index ef9943be1886..1f32537dc528 100644
--- a/drivers/infiniband/hw/bnxt_re/ib_verbs.c
+++ b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
@@ -193,7 +193,6 @@ int bnxt_re_query_device(struct ib_device *ibdev,
if (rc)
return rc;
- memset(ib_attr, 0, sizeof(*ib_attr));
memcpy(&ib_attr->fw_ver, dev_attr->fw_ver,
min(sizeof(dev_attr->fw_ver),
sizeof(ib_attr->fw_ver)));
diff --git a/drivers/infiniband/hw/efa/efa_verbs.c b/drivers/infiniband/hw/efa/efa_verbs.c
index ec124fbda637..6be8ec53dcb3 100644
--- a/drivers/infiniband/hw/efa/efa_verbs.c
+++ b/drivers/infiniband/hw/efa/efa_verbs.c
@@ -222,7 +222,6 @@ int efa_query_device(struct ib_device *ibdev,
dev_attr = &dev->dev_attr;
- memset(props, 0, sizeof(*props));
props->max_mr_size = dev_attr->max_mr_pages * PAGE_SIZE;
props->page_size_cap = dev_attr->page_size_cap;
props->vendor_id = dev->pdev->vendor;
diff --git a/drivers/infiniband/hw/erdma/erdma_verbs.c b/drivers/infiniband/hw/erdma/erdma_verbs.c
index 74afe6eb18b0..9491cbab69b3 100644
--- a/drivers/infiniband/hw/erdma/erdma_verbs.c
+++ b/drivers/infiniband/hw/erdma/erdma_verbs.c
@@ -324,8 +324,6 @@ int erdma_query_device(struct ib_device *ibdev, struct ib_device_attr *attr,
if (err)
return err;
- memset(attr, 0, sizeof(*attr));
-
attr->max_mr_size = dev->attrs.max_mr_size;
attr->vendor_id = PCI_VENDOR_ID_ALIBABA;
attr->vendor_part_id = dev->pdev->device;
diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c b/drivers/infiniband/hw/hns/hns_roce_main.c
index c6f633bd5a34..09c07de5f022 100644
--- a/drivers/infiniband/hw/hns/hns_roce_main.c
+++ b/drivers/infiniband/hw/hns/hns_roce_main.c
@@ -227,8 +227,6 @@ static int hns_roce_query_device(struct ib_device *ib_dev,
if (ret)
return ret;
- memset(props, 0, sizeof(*props));
-
props->fw_ver = hr_dev->caps.fw_ver;
props->sys_image_guid = cpu_to_be64(hr_dev->sys_image_guid);
props->max_mr_size = (u64)(~(0ULL));
diff --git a/drivers/infiniband/hw/irdma/verbs.c b/drivers/infiniband/hw/irdma/verbs.c
index 5c907ffce99b..c9b606cc67d4 100644
--- a/drivers/infiniband/hw/irdma/verbs.c
+++ b/drivers/infiniband/hw/irdma/verbs.c
@@ -22,7 +22,6 @@ static int irdma_query_device(struct ib_device *ibdev,
if (err)
return err;
- memset(props, 0, sizeof(*props));
addrconf_addr_eui48((u8 *)&props->sys_image_guid,
iwdev->netdev->dev_addr);
props->fw_ver = (u64)irdma_fw_major_ver(&rf->sc_dev) << 32 |
diff --git a/drivers/infiniband/hw/mana/main.c b/drivers/infiniband/hw/mana/main.c
index efe2935bda29..a5b3606a1dd5 100644
--- a/drivers/infiniband/hw/mana/main.c
+++ b/drivers/infiniband/hw/mana/main.c
@@ -579,7 +579,6 @@ int mana_ib_query_device(struct ib_device *ibdev, struct ib_device_attr *props,
if (err)
return err;
- memset(props, 0, sizeof(*props));
props->vendor_id = pdev->vendor;
props->vendor_part_id = dev->gdma_dev->dev_id.type;
props->max_mr_size = MANA_IB_MAX_MR_SIZE;
diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c
index 17073e8f105a..7266a6141944 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -471,8 +471,6 @@ static int mlx4_ib_query_device(struct ib_device *ibdev,
if (err)
goto out;
- memset(props, 0, sizeof *props);
-
have_ib_ports = num_ib_ports(dev->dev);
props->fw_ver = dev->dev->caps.fw_ver;
diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
index 02809114fc79..e8bba5a76d4e 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -969,7 +969,6 @@ static int mlx5_ib_query_device(struct ib_device *ibdev,
if (err)
return err;
- memset(props, 0, sizeof(*props));
err = mlx5_query_system_image_guid(ibdev,
&props->sys_image_guid);
if (err)
diff --git a/drivers/infiniband/hw/mthca/mthca_provider.c b/drivers/infiniband/hw/mthca/mthca_provider.c
index f90f67afc8fa..e933a53779a4 100644
--- a/drivers/infiniband/hw/mthca/mthca_provider.c
+++ b/drivers/infiniband/hw/mthca/mthca_provider.c
@@ -69,8 +69,6 @@ static int mthca_query_device(struct ib_device *ibdev, struct ib_device_attr *pr
goto out;
}
- memset(props, 0, sizeof *props);
-
props->fw_ver = mdev->fw_ver;
ib_init_query_mad(in_mad);
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
index 53ba32d168a1..de83dc0ea79c 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
@@ -74,7 +74,6 @@ int ocrdma_query_device(struct ib_device *ibdev, struct ib_device_attr *attr,
if (err)
return err;
- memset(attr, 0, sizeof *attr);
memcpy(&attr->fw_ver, &dev->attr.fw_ver[0],
min(sizeof(dev->attr.fw_ver), sizeof(attr->fw_ver)));
addrconf_addr_eui48((u8 *)&attr->sys_image_guid,
diff --git a/drivers/infiniband/hw/qedr/verbs.c b/drivers/infiniband/hw/qedr/verbs.c
index d5416b161340..1cf502579ad1 100644
--- a/drivers/infiniband/hw/qedr/verbs.c
+++ b/drivers/infiniband/hw/qedr/verbs.c
@@ -118,8 +118,6 @@ int qedr_query_device(struct ib_device *ibdev,
if (rc)
return rc;
- memset(attr, 0, sizeof(*attr));
-
attr->fw_ver = qattr->fw_ver;
attr->sys_image_guid = qattr->sys_image_guid;
attr->max_mr_size = qattr->max_mr_size;
diff --git a/drivers/infiniband/hw/usnic/usnic_ib_verbs.c b/drivers/infiniband/hw/usnic/usnic_ib_verbs.c
index dc355b00f61c..3402c84eb904 100644
--- a/drivers/infiniband/hw/usnic/usnic_ib_verbs.c
+++ b/drivers/infiniband/hw/usnic/usnic_ib_verbs.c
@@ -284,7 +284,6 @@ int usnic_ib_query_device(struct ib_device *ibdev,
mutex_lock(&us_ibdev->usdev_lock);
us_ibdev->netdev->ethtool_ops->get_drvinfo(us_ibdev->netdev, &info);
- memset(props, 0, sizeof(*props));
usnic_mac_ip_to_gid(us_ibdev->ufdev->mac, us_ibdev->ufdev->inaddr,
&gid.raw[0]);
memcpy(&props->sys_image_guid, &gid.global.interface_id,
diff --git a/drivers/infiniband/sw/siw/siw_verbs.c b/drivers/infiniband/sw/siw/siw_verbs.c
index b74ac85c1b8b..e281517fc6f9 100644
--- a/drivers/infiniband/sw/siw/siw_verbs.c
+++ b/drivers/infiniband/sw/siw/siw_verbs.c
@@ -136,8 +136,6 @@ int siw_query_device(struct ib_device *base_dev, struct ib_device_attr *attr,
if (rv)
return rv;
- memset(attr, 0, sizeof(*attr));
-
/* Revisit atomic caps if RFC 7306 gets supported */
attr->atomic_cap = 0;
attr->device_cap_flags = IB_DEVICE_MEM_MGT_EXTENSIONS;
--
2.54.0
^ permalink raw reply related
* [PATCH rdma-next 1/2] RDMA/bnxt_re: Validate udata before destroying resources
From: Leon Romanovsky @ 2026-07-13 8:10 UTC (permalink / raw)
To: Selvin Xavier, Kalesh AP, Jason Gunthorpe, Leon Romanovsky,
Michael Margolin, Gal Pressman, Yossi Leybovich, Cheng Xu,
Kai Shen, Chengchang Tang, Junxian Huang, Tatyana Nikolova,
Long Li, Konstantin Taranov, Yishai Hadas, Michal Kalderon,
Nelson Escobar, Satish Kharat, Bernard Metzler
Cc: linux-rdma, linux-kernel, linux-hyperv
In-Reply-To: <20260713-fix-destroy-no-udata-v1-0-fcca2e34fd57@nvidia.com>
From: Leon Romanovsky <leonro@nvidia.com>
The destroy callbacks currently zero the udata output after tearing down
their resources. If that userspace access fails, uverbs preserves the
uobject and permits the destroy callback to be entered again even though
the driver resource has already been released.
Use ib_no_udata_io() before teardown so all udata failures occur while the
resource is still intact, then return success after teardown completes.
Fixes: bed686d8dcd4 ("RDMA/bnxt_re: Use ib_respond_empty_udata()")
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
drivers/infiniband/hw/bnxt_re/ib_verbs.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/infiniband/hw/bnxt_re/ib_verbs.c b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
index 565762529007..ef9943be1886 100644
--- a/drivers/infiniband/hw/bnxt_re/ib_verbs.c
+++ b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
@@ -695,7 +695,7 @@ int bnxt_re_dealloc_pd(struct ib_pd *ib_pd, struct ib_udata *udata)
struct bnxt_re_dev *rdev = pd->rdev;
int ret;
- ret = ib_is_udata_in_empty(udata);
+ ret = ib_no_udata_io(udata);
if (ret)
return ret;
@@ -712,7 +712,7 @@ int bnxt_re_dealloc_pd(struct ib_pd *ib_pd, struct ib_udata *udata)
&pd->qplib_pd))
atomic_dec(&rdev->stats.res.pd_count);
}
- return ib_respond_empty_udata(udata);
+ return 0;
}
int bnxt_re_alloc_pd(struct ib_pd *ibpd, struct ib_udata *udata)
@@ -1015,7 +1015,7 @@ int bnxt_re_destroy_qp(struct ib_qp *ib_qp, struct ib_udata *udata)
unsigned int flags;
int rc;
- rc = ib_is_udata_in_empty(udata);
+ rc = ib_no_udata_io(udata);
if (rc)
return rc;
@@ -1064,7 +1064,7 @@ int bnxt_re_destroy_qp(struct ib_qp *ib_qp, struct ib_udata *udata)
if (scq_nq != rcq_nq)
bnxt_re_synchronize_nq(rcq_nq);
- return ib_respond_empty_udata(udata);
+ return 0;
}
static u8 __from_ib_qp_type(enum ib_qp_type type)
@@ -2148,7 +2148,7 @@ int bnxt_re_destroy_srq(struct ib_srq *ib_srq, struct ib_udata *udata)
struct bnxt_qplib_srq *qplib_srq = &srq->qplib_srq;
int ret;
- ret = ib_is_udata_in_empty(udata);
+ ret = ib_no_udata_io(udata);
if (ret)
return ret;
@@ -2159,7 +2159,7 @@ int bnxt_re_destroy_srq(struct ib_srq *ib_srq, struct ib_udata *udata)
free_page((unsigned long)srq->uctx_srq_page);
ib_umem_release(srq->umem);
atomic_dec(&rdev->stats.res.srq_count);
- return ib_respond_empty_udata(udata);
+ return 0;
}
static int bnxt_re_init_user_srq(struct bnxt_re_dev *rdev,
@@ -3471,7 +3471,7 @@ int bnxt_re_destroy_cq(struct ib_cq *ib_cq, struct ib_udata *udata)
nq = cq->qplib_cq.nq;
cctx = rdev->chip_ctx;
- ret = ib_is_udata_in_empty(udata);
+ ret = ib_no_udata_io(udata);
if (ret)
return ret;
@@ -3486,7 +3486,7 @@ int bnxt_re_destroy_cq(struct ib_cq *ib_cq, struct ib_udata *udata)
atomic_dec(&rdev->stats.res.cq_count);
kfree(cq->cql);
ib_umem_release(cq->umem);
- return ib_respond_empty_udata(udata);
+ return 0;
}
int bnxt_re_create_user_cq(struct ib_cq *ibcq, const struct ib_cq_init_attr *attr,
@@ -4449,7 +4449,7 @@ int bnxt_re_dereg_mr(struct ib_mr *ib_mr, struct ib_udata *udata)
struct bnxt_re_dev *rdev = mr->rdev;
int rc;
- rc = ib_is_udata_in_empty(udata);
+ rc = ib_no_udata_io(udata);
if (rc)
return rc;
@@ -4472,7 +4472,7 @@ int bnxt_re_dereg_mr(struct ib_mr *ib_mr, struct ib_udata *udata)
atomic_dec(&rdev->stats.res.mr_count);
if (rc)
return rc;
- return ib_respond_empty_udata(udata);
+ return 0;
}
static int bnxt_re_set_page(struct ib_mr *ib_mr, u64 addr)
--
2.54.0
^ permalink raw reply related
* [PATCH rdma-next 0/2] RDMA: Small batch of cleanups
From: Leon Romanovsky @ 2026-07-13 8:10 UTC (permalink / raw)
To: Selvin Xavier, Kalesh AP, Jason Gunthorpe, Leon Romanovsky,
Michael Margolin, Gal Pressman, Yossi Leybovich, Cheng Xu,
Kai Shen, Chengchang Tang, Junxian Huang, Tatyana Nikolova,
Long Li, Konstantin Taranov, Yishai Hadas, Michal Kalderon,
Nelson Escobar, Satish Kharat, Bernard Metzler
Cc: linux-rdma, linux-kernel, linux-hyperv
This series contains two independent cleanups. One fixes the problematic placemen
of a newly introduced in-kernel API, which should be called at the beginning of
destroy functions and not at the end. The other removes a redundant memset().
Thanks.
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
Leon Romanovsky (2):
RDMA/bnxt_re: Validate udata before destroying resources
RDMA: Remove redundant memset() from query_device callbacks
drivers/infiniband/hw/bnxt_re/ib_verbs.c | 21 ++++++++++-----------
drivers/infiniband/hw/efa/efa_verbs.c | 1 -
drivers/infiniband/hw/erdma/erdma_verbs.c | 2 --
drivers/infiniband/hw/hns/hns_roce_main.c | 2 --
drivers/infiniband/hw/irdma/verbs.c | 1 -
drivers/infiniband/hw/mana/main.c | 1 -
drivers/infiniband/hw/mlx4/main.c | 2 --
drivers/infiniband/hw/mlx5/main.c | 1 -
drivers/infiniband/hw/mthca/mthca_provider.c | 2 --
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 1 -
drivers/infiniband/hw/qedr/verbs.c | 2 --
drivers/infiniband/hw/usnic/usnic_ib_verbs.c | 1 -
drivers/infiniband/sw/siw/siw_verbs.c | 2 --
13 files changed, 10 insertions(+), 29 deletions(-)
---
base-commit: 15ae32c4a3551c4c9da457370bdfdd65d171e512
change-id: 20260712-fix-destroy-no-udata-dfa990b985ea
Best regards,
--
Leon Romanovsky <leonro@nvidia.com>
^ permalink raw reply
* Re: [PATCH] net: mana: cap HWC init max message size to HW_CHANNEL_MAX_REQUEST_SIZE
From: sashiko-bot @ 2026-07-12 15:06 UTC (permalink / raw)
To: Michael Bommarito; +Cc: linux-hyperv
In-Reply-To: <20260711150628.2914205-1-michael.bommarito@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [Medium] The commit message describes an integer overflow vulnerability in `mana_hwc_alloc_dma_buf()` caused by using unbounded device-advertised message sizes, but this vulnerability is entirely hallucinated and the modified variables are dead code.
- [Low] The patch incorrectly clamps `HWC_INIT_DATA_MAX_RESPONSE` using `HW_CHANNEL_MAX_REQUEST_SIZE` instead of `HW_CHANNEL_MAX_RESPONSE_SIZE`.
Pre-existing issues:
- [High] An unchecked `eq_db.doorbell` index from a hardware event causes an out-of-bounds MMIO write during doorbell ringing.
- [High] An unchecked `max_num_cqs` value retrieved from the hardware event allows a malicious device to trigger enormous kernel memory allocations.
--
--- Patch [1]: [PATCH] net: mana: cap HWC init max message size to HW_CHANNEL_MAX_REQUEST_SIZE ---
commit ea80048daa839e9f12f06618139e15fddebc0ac5
Author: Michael Bommarito <michael.bommarito@gmail.com>
net: mana: cap HWC init max message size to HW_CHANNEL_MAX_REQUEST_SIZE
The commit adds bounds checking for max message size during HWC initialization.
It claims this prevents an out-of-bounds DMA buffer write in
mana_hwc_alloc_dma_buf().
> mana_hwc_init_event_handler() in hw_channel.c stores device-advertised
> HWC_INIT_DATA_MAX_REQUEST and HWC_INIT_DATA_MAX_RESPONSE values
> without bounds checking. mana_hwc_alloc_dma_buf() later computes the
> DMA buffer size as MANA_PAGE_ALIGN(q_depth * max_msg_size) in 32-bit
> arithmetic. A malicious device returning a large max_msg_size causes
> the product to wrap, allocating a small buffer while laying out
> q_depth request slots at the unwrapped stride, placing slots outside
> the allocation.
[Severity: Medium]
Is this description accurate?
The modified variables (hwc->hwc_init_max_req_msg_size and
hwc->hwc_init_max_resp_msg_size) appear to be dead code that do not affect
memory allocation. mana_hwc_alloc_dma_buf() is invoked before the event
handler runs (via mana_hwc_init_queues()) using hardcoded sizes (4096),
not the hardware-provided ones.
> diff --git a/drivers/net/ethernet/microsoft/mana/hw_channel.c b/drivers/net/ethernet/microsoft/mana/hw_channel.c
> index e3c24d50dad07..94594fba112f9 100644
> --- a/drivers/net/ethernet/microsoft/mana/hw_channel.c
> +++ b/drivers/net/ethernet/microsoft/mana/hw_channel.c
> @@ -150,10 +150,14 @@ static void mana_hwc_init_event_handler(void *ctx, struct gdma_queue *q_self,
> break;
>
> case HWC_INIT_DATA_MAX_REQUEST:
> + if (val == 0 || val > HW_CHANNEL_MAX_REQUEST_SIZE)
> + val = HW_CHANNEL_MAX_REQUEST_SIZE;
> hwc->hwc_init_max_req_msg_size = val;
> break;
>
> case HWC_INIT_DATA_MAX_RESPONSE:
> + if (val == 0 || val > HW_CHANNEL_MAX_REQUEST_SIZE)
> + val = HW_CHANNEL_MAX_REQUEST_SIZE;
[Severity: Low]
Does this incorrectly clamp HWC_INIT_DATA_MAX_RESPONSE using
HW_CHANNEL_MAX_REQUEST_SIZE instead of HW_CHANNEL_MAX_RESPONSE_SIZE?
> hwc->hwc_init_max_resp_msg_size = val;
> break;
>
[Severity: High]
This is a pre-existing issue, but is it possible for a malicious device
to trigger an out-of-bounds MMIO write via an unchecked doorbell index?
Earlier in mana_hwc_init_event_handler():
case GDMA_EQE_HWC_INIT_EQ_ID_DB:
eq_db.as_uint32 = event->details[0];
hwc->cq->gdma_eq->id = eq_db.eq_id;
gd->doorbell = eq_db.doorbell;
When the driver posts WQEs and rings the doorbell via mana_gd_ring_doorbell():
drivers/net/ethernet/microsoft/mana/gdma_main.c:mana_gd_ring_doorbell() {
...
void __iomem *addr = gc->db_page_base + gc->db_page_size * db_index;
...
writeq(e.as_uint64, addr);
...
}
If eq_db.doorbell is excessively large, could it calculate a memory-mapped
address that exceeds gc->bar0_size, resulting in an out-of-bounds writeq()
that corrupts adjacent mappings?
[Severity: High]
This is a pre-existing issue, but does the unchecked max_num_cqs value
allow a malicious device to exhaust system memory?
Later in mana_hwc_init_event_handler():
case HWC_INIT_DATA_MAX_NUM_CQS:
gd->gdma_context->max_num_cqs = val;
break;
This unbounded max_num_cqs value is later used for memory allocation:
drivers/net/ethernet/microsoft/mana/hw_channel.c:mana_hwc_establish_channel() {
...
gc->cq_table = vcalloc(gc->max_num_cqs, sizeof(struct gdma_queue *));
...
}
If max_num_cqs is an exceptionally large 32-bit value (e.g., 0x1FFFFFFF),
could vcalloc() attempt to allocate multiple gigabytes of memory and cause a
host-level denial of service?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260711150628.2914205-1-michael.bommarito@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH net-next v12 4/4] net: mana: recover port on attach failure in ethtool operations
From: sashiko-bot @ 2026-07-12 4:14 UTC (permalink / raw)
To: Dipayaan Roy; +Cc: bpf, linux-hyperv
In-Reply-To: <20260711041415.3008868-5-dipayanroy@linux.microsoft.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
New issues:
- [High] The newly introduced background recovery via `queue_reset_work` races with administrative interface state changes (`ip link set down`), causing the port to become permanently stuck in a broken state.
- [High] Clearing `channel_changing` before queuing `queue_reset_work` in `mana_set_channels` creates a race window where the RDMA driver can claim the vport, permanently defeating the recovery.
Pre-existing issues:
- [Critical] A failure in `mana_attach()` leaves the driver vulnerable to a guaranteed NULL pointer dereference when the port is later brought up via `ip link set up`.
- [High] Missing RDMA synchronization via the `channel_changing` flag in `mana_set_ringparam`, `mana_change_mtu`, and `mana_xdp_set` allows the RDMA driver to hijack the vport during configuration changes.
- [Medium] The fix for `mana_attach()` failures leaving the port in a broken state was applied to ethtool ring size and channel count changes, but missed MTU changes and XDP program attachment.
--
--- Patch [4]: [PATCH net-next v12 4/4] net: mana: recover port on attach failure in ethtool operations ---
commit 750fd303cde77a7c9585144b5c7341d83090dbb3
Author: Dipayaan Roy <dipayanroy@linux.microsoft.com>
net: mana: recover port on attach failure in ethtool operations
This patch adds a recovery mechanism for mana_attach() failures during ethtool
ring size or channel count changes by scheduling queue_reset_work, while
adjusting retry values to maximize the chance of recovery.
> diff --git a/drivers/net/ethernet/microsoft/mana/mana_ethtool.c b/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
> index f77509818d07f..71e69d5a9a04a 100644
> --- a/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
> +++ b/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
> @@ -675,8 +676,19 @@ static int mana_set_channels(struct net_device *ndev,
> apc->num_queues = new_count;
> err = mana_attach(ndev);
> if (err) {
> - apc->num_queues = old_count;
> netdev_err(ndev, "mana_attach failed: %d\n", err);
> +
> + /* Choose a retry queue count that maximizes recovery
> + * chances in the reset work handler.
> + */
> + if (old_count < new_count)
> + apc->num_queues = old_count;
> + else if (new_count > MANA_DEF_NUM_QUEUES)
> + apc->num_queues = MANA_DEF_NUM_QUEUES;
> + else
> + apc->num_queues = 1;
> +
> + schedule_port_reset = true;
> }
[Severity: Critical]
This is a pre-existing issue, but a failure in mana_attach() leaves the driver
vulnerable to a NULL pointer dereference when the port is later brought up
manually.
If mana_attach() fails, its failure path calls mana_cleanup_port_context()
which frees apc->rxqs:
drivers/net/ethernet/microsoft/mana/mana_en.c:mana_cleanup_port_context() {
...
kfree(apc->rxqs);
apc->rxqs = NULL;
...
}
If the user later brings the interface up, mana_open() triggers the queue
allocation chain without reinitializing the port context:
drivers/net/ethernet/microsoft/mana/mana_en.c:mana_open() {
...
err = mana_alloc_queues(ndev);
...
}
Which dereferences the NULL pointer in mana_add_rx_queues():
drivers/net/ethernet/microsoft/mana/mana_en.c:mana_add_rx_queues() {
...
apc->rxqs[i] = rxq;
...
}
Is there a mechanism to prevent this sequence if recovery fails?
> out:
> @@ -685,6 +697,11 @@ static int mana_set_channels(struct net_device *ndev,
> mutex_lock(&apc->vport_mutex);
> apc->channel_changing = false;
> mutex_unlock(&apc->vport_mutex);
[Severity: High]
Could clearing channel_changing before the reset work executes create a race
condition where the RDMA driver claims the vport?
If mana_set_channels() fails in mana_attach() and drops vport_mutex while
setting apc->channel_changing = false, a concurrent RDMA QP creation could
call mana_cfg_vport() and successfully claim the hardware vport since
vport_use_count is 0.
When the queued reset work later calls mana_attach() -> mana_create_vport(),
it would see vport_use_count as 1 and fail with -EBUSY, preventing the
recovery from succeeding.
Should channel_changing remain true until the recovery completes?
> +
> + if (schedule_port_reset)
> + queue_work(apc->ac->per_port_queue_reset_wq,
> + &apc->queue_reset_work);
> +
> return err;
> }
[Severity: High]
Can this asynchronous recovery race with administrative interface state changes,
leaving the port in a state where it cannot be brought up or down?
If an admin runs ip link set down before the reset workqueue executes:
drivers/net/ethernet/microsoft/mana/mana_en.c:mana_close() {
if (!apc->port_is_up)
return 0;
...
}
Because mana_close() returns early, apc->port_st_save remains true, while the
kernel state transitions to DOWN.
When the reset work runs, it calls mana_attach() which sees
port_st_save == true, reallocates queues, increments vport_use_count to 1,
and sets apc->port_is_up = true.
If the admin then runs ip link set up, mana_open() will fail in
mana_create_vport() with -EBUSY because vport_use_count is already 1. A
subsequent ip link set down will do nothing because the kernel state is
already DOWN.
Does the reset work handler need to synchronize against administrative state
changes?
[ ... ]
> @@ -752,11 +770,35 @@ static int mana_set_ringparam(struct net_device *ndev,
> err = mana_attach(ndev);
> if (err) {
[Severity: High]
This isn't a bug introduced by this patch, but does the detach and attach
sequence here lack synchronization against the RDMA driver?
Unlike mana_set_channels(), mana_set_ringparam() does not acquire
vport_mutex or set apc->channel_changing = true before calling mana_detach().
When it calls mana_detach(ndev, false), vport_use_count drops to 0. A
concurrent RDMA workload could call mana_cfg_vport() and claim the vport
during this window.
When the Ethernet driver subsequently calls mana_attach(), it would fail with
-EBUSY.
This same lack of synchronization appears to be present in mana_change_mtu()
and mana_xdp_set().
> netdev_err(ndev, "mana_attach failed: %d\n", err);
> - apc->tx_queue_size = old_tx;
> - apc->rx_queue_size = old_rx;
> + NL_SET_ERR_MSG_FMT(extack, "failed to change ring params: %d",
> + err);
> +
> + /* Choose retry ring sizes that maximize recovery
> + * chances in the reset work handler. Handle RX and
> + * TX independently.
> + */
> + if (old_rx < new_rx)
> + apc->rx_queue_size = old_rx;
> + else if (new_rx > DEF_RX_BUFFERS_PER_QUEUE)
> + apc->rx_queue_size = DEF_RX_BUFFERS_PER_QUEUE;
> + else
> + apc->rx_queue_size = MIN_RX_BUFFERS_PER_QUEUE;
> +
> + if (old_tx < new_tx)
> + apc->tx_queue_size = old_tx;
> + else if (new_tx > DEF_TX_BUFFERS_PER_QUEUE)
> + apc->tx_queue_size = DEF_TX_BUFFERS_PER_QUEUE;
> + else
> + apc->tx_queue_size = MIN_TX_BUFFERS_PER_QUEUE;
> +
> + schedule_port_reset = true;
> }
> out:
> mana_pre_dealloc_rxbufs(apc);
> +
> + if (schedule_port_reset)
> + queue_work(apc->ac->per_port_queue_reset_wq,
> + &apc->queue_reset_work);
> return err;
> }
[Severity: Medium]
This is a pre-existing issue, but should this same recovery mechanism be
applied to MTU and XDP program changes?
If mana_attach() fails in mana_change_mtu() or mana_xdp_set(), they return
immediately without scheduling queue_reset_work. This leaves the port detached,
which eventually leads to the NULL pointer dereference in mana_open() if the
user tries to bring the interface up manually.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260711041415.3008868-1-dipayanroy@linux.microsoft.com?part=4
^ permalink raw reply
* Re: [PATCH net-next v4] net: mana: Add handler for sriov configure
From: sashiko-bot @ 2026-07-11 19:27 UTC (permalink / raw)
To: Haiyang Zhang; +Cc: linux-hyperv
In-Reply-To: <20260710192735.2921300-1-haiyangz@linux.microsoft.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Uncancelled background works (`mana_serv_work` and `mana_dev_recovery_work`) lead to Use-After-Free of `gdma_context` during device removal.
--
--- Patch [1]: [PATCH net-next v4] net: mana: Add handler for sriov configure ---
commit d651d90ceb3e1716b100c2eb4035662f066b67fa
Author: Haiyang Zhang <haiyangz@microsoft.com>
net: mana: Add handler for sriov configure
This commit adds a callback function for the pci_driver / sriov_configure
interface. It requests the NIC to provide a specific number of VFs, or
disables VFs if the requested number is zero.
> diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> index aef3b77229c13..a38d4bb74621f 100644
> --- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
> +++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> @@ -2456,6 +2456,8 @@ static void mana_gd_remove(struct pci_dev *pdev)
> {
> struct gdma_context *gc = pci_get_drvdata(pdev);
>
> + pci_disable_sriov(pdev);
> +
> mana_rdma_remove(&gc->mana_ib);
> mana_remove(&gc->mana, false);
[Severity: High]
This is a pre-existing issue, but can this lead to a Use-After-Free of
gdma_context if there are uncancelled background works?
When mana_gd_remove() executes, it eventually frees the gdma_context via
vfree(gc) without flushing works like mana_serv_work or
mana_dev_recovery_work that might be pending on the system_wq.
If a hardware event triggers mana_gd_process_eqe() and schedules
serv_work before a hot-unplug, could the scheduled work run after
mana_gd_remove() has freed the context?
The worker thread mana_serv_func() calls mana_serv_reset(), which does:
struct gdma_context *gc = pci_get_drvdata(pdev);
...
hwc = gc->hwc.driver_data;
Since the PCI core only clears drvdata after remove() returns, this could
dereference the freed gc memory. Should these background works be
cancelled before freeing the context?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260710192735.2921300-1-haiyangz@linux.microsoft.com?part=1
^ permalink raw reply
* RE: [PATCH v2 3/4] iommu/hyperv: Add para-virtualized IOMMU support for Hyper-V guest
From: Michael Kelley @ 2026-07-11 18:31 UTC (permalink / raw)
To: Yu Zhang
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
iommu@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arch@vger.kernel.org, wei.liu@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, decui@microsoft.com, longli@microsoft.com,
joro@8bytes.org, will@kernel.org, robin.murphy@arm.com,
bhelgaas@google.com, kwilczynski@kernel.org,
lpieralisi@kernel.org, mani@kernel.org, robh@kernel.org,
arnd@arndb.de, jgg@ziepe.ca, jacob.pan@linux.microsoft.com,
tgopinath@linux.microsoft.com,
easwar.hariharan@linux.microsoft.com, mrathor@linux.microsoft.com
In-Reply-To: <enpkphavwmqrkded73c43vprczslvei4755lkxuedof4z2k3kk@y2jtklbk4efz>
From: Yu Zhang <zhangyu1@linux.microsoft.com> Sent: Friday, July 10, 2026 12:34 AM
>
> On Thu, Jul 09, 2026 at 07:08:26PM +0000, Michael Kelley wrote:
> > From: Yu Zhang <zhangyu1@linux.microsoft.com> Sent: Thursday, July 2, 2026 9:05 AM
> > >
> > > Add a para-virtualized IOMMU driver for Linux guests running on Hyper-V.
> > > This driver implements stage-1 IO translation within the guest OS.
> > > It integrates with the Linux IOMMU core, utilizing Hyper-V hypercalls
> > > for:
> > > - Capability discovery
> > > - Domain allocation, configuration, and deallocation
> > > - Device attachment and detachment
> > > - IOTLB invalidation
> > >
> > > The driver constructs x86-compatible stage-1 IO page tables in the
> > > guest memory using consolidated IO page table helpers. This allows
> > > the guest to manage stage-1 translations independently of vendor-
> > > specific drivers (like Intel VT-d or AMD IOMMU).
> > >
> > > Hyper-V consumes this stage-1 IO page table when a device domain is
> > > created and configured, and nests it with the host's stage-2 IO page
> > > tables, therefore eliminating the VM exits for guest IOMMU mapping
> > > operations. For unmapping operations, VM exits to perform the IOTLB
> > > flush are still unavoidable.
> > >
> > > To identify a device in its hypercall interface, the driver looks up the
> > > logical device ID prefix registered for the device's PCI domain (see the
> > > logical device ID registry in hv_common.c) and combines it with the PCI
> > > function number of the endpoint device.
> > >
> > > Co-developed-by: Wei Liu <wei.liu@kernel.org>
> > > Signed-off-by: Wei Liu <wei.liu@kernel.org>
> > > Co-developed-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
> > > Signed-off-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
> > > Signed-off-by: Yu Zhang <zhangyu1@linux.microsoft.com>
> > > ---
> > > arch/x86/hyperv/hv_init.c | 4 +
> > > arch/x86/include/asm/mshyperv.h | 4 +
> > > drivers/iommu/Kconfig | 1 +
> > > drivers/iommu/hyperv/Kconfig | 16 +
> > > drivers/iommu/hyperv/Makefile | 1 +
> > > drivers/iommu/hyperv/iommu.c | 620 ++++++++++++++++++++++++++++++++
> > > drivers/iommu/hyperv/iommu.h | 51 +++
> > > 7 files changed, 697 insertions(+)
> > > create mode 100644 drivers/iommu/hyperv/Kconfig
> > > create mode 100644 drivers/iommu/hyperv/iommu.c
> > > create mode 100644 drivers/iommu/hyperv/iommu.h
> > >
> > > diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> > > index 55a8b6de2865..094f9f7ddb72 100644
> > > --- a/arch/x86/hyperv/hv_init.c
> > > +++ b/arch/x86/hyperv/hv_init.c
> > > @@ -578,6 +578,10 @@ void __init hyperv_init(void)
> > > old_setup_percpu_clockev = x86_init.timers.setup_percpu_clockev;
> > > x86_init.timers.setup_percpu_clockev = hv_stimer_setup_percpu_clockev;
> > >
> > > +#ifdef CONFIG_HYPERV_PVIOMMU
> > > + x86_init.iommu.iommu_init = hv_iommu_init;
> > > +#endif
> > > +
> >
> > This approach to .iommu_init is a bit different from the Intel VT-d and
> > AMD IOMMU initialization. Those cases detect the existence of the
> > IOMMU first via a "detect" function that is called in pci_iommu_alloc().
> > If the detect function finds an IOMMU, it sets .iommu_init. Any
> > reason not to use the same approach for the Hyper-V pvIOMMU?
> > One problem with exactly the same approach is that Hyper-V
> > hypercalls aren't set up at the time pci_iommu_alloc() runs.
>
> Yes. That's why I did not follow Intel VT-d and AMD IOMMU's approach -
> the hv_hypercall_pg is not ready yet.
>
> > So you'd have to call the "detect" function here in hyperv_init(),
> > and have the detect function set .iommu_init if pvIOMMU
> > support is present.
> >
>
> The detecion of the presense and capabilities of the pvIOMMU are done
> in one hypercall. But I guess we can:
> - do the HVCALL_GET_IOMMU_CAPABILITIES in hyperv_init();
> - check the presense and only set .iommu_init to hyperv_iommu_init()
> if pvIOMMU is present;
> - and then do other capalibities check in hv_iommu_init();
> - only give the error log if an pvIOMMU is present yet its capabilities
> are not legal.
> So below errors will not be printed for guest kernels built with
> CONFIG_HYPERV_PVIOMMU and running on a host w/o one.
I see your point about detection and capabilities coming from
single hypercall, and that separating those two functions
would duplicate code. My biggest concern is about errors in the
dmesg log for a valid configuration where the host doesn't
supply a pvIOMMU. Fixing that problem in the context of the
current code structure would be acceptable.
A minor concern is arguably misusing the .iommu_init function
to do detection. But that function is only called once at boot
time, so leaving it set to hv_iommu_init() even if there isn't
a Hyper-V pvIOMMU is probably more a conceptual issue
than a real issue. I wouldn't object if you prefer to leave that
"as is" to avoid duplicating the hypercall.
One new thought: Have you considered the hibernate/resume
cycle? Does anything need to be done with the pvIOMMU to
make it functional again after resume? I see that the Intel and
AMD IOMMU drivers have suspend and resume functions. I
don't know enough about the Hyper-V pvIOMMU to know if it
might also need suspend and resume functions.
Michael
>
> > While the code currently in this patch works, it generates boot
> > time errors if the kernel is built with CONFIG_HYPERV_PVIOMMU
> > but run in a guest on a host without pvIOMMU support:
> >
> > [ 0.101673] Hyper-V pvIOMMU: HVCALL_GET_IOMMU_CAPABILITIES failed, status 2
> > [ 0.101675] Hyper-V pvIOMMU: HVCALL_GET_IOMMU_CAPABILITIES failed: -22
> >
> > We really don't want errors if it's just the case that there's no
> > pvIOMMU support. A less alarming message (at INFO level instead
> > of ERROR level) about running without an IOMMU might be OK, but
> > perhaps is unnecessary since you have an INFO message if the
> > pvIOMMU is found and successfully initialized.
> >
^ permalink raw reply
* RE: [PATCH] hv: hv_balloon: validate unballoon range count
From: Michael Kelley @ 2026-07-11 18:09 UTC (permalink / raw)
To: Michael Bommarito, kys@microsoft.com, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li
Cc: Greg Kroah-Hartman, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <20260710022914.3740453-1-michael.bommarito@gmail.com>
From: Michael Bommarito <michael.bommarito@gmail.com> Sent: Thursday, July 9, 2026 7:29 PM
>
> The Hyper-V dynamic memory host supplies DM_UNBALLOON_REQUEST messages
> with a header size and a range_count field. balloon_down() trusts
> range_count and walks req->range_array without checking that the received
> message contains that many ranges.
>
> A malformed host or backend message can therefore make the guest read
> past the received VMBus packet while freeing balloon ranges. Validate the
> received message size and reject range_count values that exceed the
> present range array before walking it.
Same comment applies here as I wrote for your proposed validations for
the Hyper-V mouse driver. The balloon driver also has .allowed_in_isolated
set to false, so it isn't loaded in a CoCo VM and it hasn't been hardened
for the "untrusted host" threat model.
Michael
>
> Impact: A malicious Hyper-V host or backend can crash a guest by sending
> a short unballoon request with an oversized range_count.
>
> Fixes: 9aa8b50b2b3d ("Drivers: hv: Add Hyper-V balloon driver")
> Cc: stable@vger.kernel.org
> Assisted-by: Codex:gpt-5-5-xhigh
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> ---
> drivers/hv/hv_balloon.c | 26 ++++++++++++++++++++++++--
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
> index a848400a59a2d..f5bc8c9fea7b9 100644
> --- a/drivers/hv/hv_balloon.c
> +++ b/drivers/hv/hv_balloon.c
> @@ -1337,8 +1337,23 @@ static void balloon_up(struct work_struct *dummy)
> }
> }
>
> +static bool unballoon_request_valid(struct dm_unballoon_request *req,
> + u32 msg_size)
> +{
> + u32 max_ranges;
> +
> + if (msg_size < sizeof(*req) || req->hdr.size < sizeof(*req) ||
> + req->hdr.size > msg_size)
> + return false;
> +
> + max_ranges = (req->hdr.size - sizeof(*req)) /
> + sizeof(req->range_array[0]);
> +
> + return req->range_count <= max_ranges;
> +}
> +
> static void balloon_down(struct hv_dynmem_device *dm,
> - struct dm_unballoon_request *req)
> + struct dm_unballoon_request *req, u32 msg_size)
> {
> union dm_mem_page_range *range_array = req->range_array;
> int range_count = req->range_count;
> @@ -1346,6 +1361,12 @@ static void balloon_down(struct hv_dynmem_device *dm,
> int i;
> unsigned int prev_pages_ballooned = dm->num_pages_ballooned;
>
> + if (!unballoon_request_valid(req, msg_size)) {
> + pr_warn_ratelimited("Invalid unballoon request: size %u, header size
> %u, range count %u\n",
> + msg_size, req->hdr.size, req->range_count);
> + return;
> + }
> +
> for (i = 0; i < range_count; i++) {
> free_balloon_pages(dm, &range_array[i]);
> complete(&dm_device.config_event);
> @@ -1527,7 +1548,8 @@ static void balloon_onchannelcallback(void *context)
>
> dm->state = DM_BALLOON_DOWN;
> balloon_down(dm,
> - (struct dm_unballoon_request *)recv_buffer);
> + (struct dm_unballoon_request *)recv_buffer,
> + recvlen);
> break;
>
> case DM_MEM_HOT_ADD_REQUEST:
> --
> 2.53.0
^ permalink raw reply
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