* Re: [PATCH] vsock: use sock_error() to consume sk_err after connect timeout
From: Michal Luczaj @ 2026-07-23 6:00 UTC (permalink / raw)
To: Nguyen Dinh Phi [SG], Stefano Garzarella
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, syzbot+1b2c9c4a0f8708082678, virtualization, netdev,
linux-kernel
In-Reply-To: <b81bfea4-6b19-4cc8-95c0-dcd4ad42476e@gmail.com>
On 7/23/26 06:14, Nguyen Dinh Phi [SG] wrote:
> On 22/7/26 15:55, Stefano Garzarella wrote:
>> On Tue, Jul 21, 2026 at 01:34:03AM +0800, Phi Nguyen wrote:
>>> On 7/20/2026 4:17 PM, Stefano Garzarella wrote:
>>>> On Mon, Jul 20, 2026 at 05:57:47AM +0800, Nguyen Dinh Phi wrote:
>>>>> After vsock_connect() exits the wait loop due to sk->sk_err being
>>>>> set, the error was read but not cleared. This left sk->sk_err set
>>>>> for subsequent operations.
>>>>
>>>> So, is this a fix? If yes, we should put a Fixes tag.
>>>>
>>>> Also, can you describe how to trigger the issue?
>>>>
>>>> Because I see this in vsock_connect(), so I thought it was in some
>>>> way already handled:
>>>>
>>>> /* sk_err might have been set as a result of an earlier
>>>> * (failed) connect attempt.
>>>> */
>>>> sk->sk_err = 0;
>>>>
>>> This only handles the case where the function following the failed
>>> connect is another connect() call.
>>
>> So, can we remove that with this patch, or better to leave as defensive
>> action?
>>
>
> I prefer to keep it here as defensive action
Is changing how vsock_poll() behaves intended?
I.e. if sk_err should be kept after a failed connect(), what about
`sk->sk_err = 0;` in vsock_listen() instead?
>> ...
>> Yeah, we need to handle that part better, I think it's a leftover when
>> we generalized AF_VSOCK to support more transport than vmci.
Speaking of leftovers, I have trouble understanding where does vsock set
sk_err on listener sockets anyway. If it doesn't, why vsock_accept() checks
for it?
thanks,
Michal
^ permalink raw reply
* Re: [PATCH] vsock: use sock_error() to consume sk_err after connect timeout
From: Nguyen Dinh Phi [SG] @ 2026-07-23 4:14 UTC (permalink / raw)
To: Stefano Garzarella
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, syzbot+1b2c9c4a0f8708082678, virtualization, netdev,
linux-kernel
In-Reply-To: <amB15TdzPAEk9A9C@sgarzare-redhat>
On 22/7/26 15:55, Stefano Garzarella wrote:
> On Tue, Jul 21, 2026 at 01:34:03AM +0800, Phi Nguyen wrote:
>> On 7/20/2026 4:17 PM, Stefano Garzarella wrote:
>>> On Mon, Jul 20, 2026 at 05:57:47AM +0800, Nguyen Dinh Phi wrote:
>>>> After vsock_connect() exits the wait loop due to sk->sk_err being
>>>> set, the error was read but not cleared. This left sk->sk_err set
>>>> for subsequent operations.
>>>
>>> So, is this a fix? If yes, we should put a Fixes tag.
>>>
>>> Also, can you describe how to trigger the issue?
>>>
>>> Because I see this in vsock_connect(), so I thought it was in some
>>> way already handled:
>>>
>>> /* sk_err might have been set as a result of an earlier
>>> * (failed) connect attempt.
>>> */
>>> sk->sk_err = 0;
>>>
>> This only handles the case where the function following the failed
>> connect is another connect() call.
>
> So, can we remove that with this patch, or better to leave as defensive
> action?
>
I prefer to keep it here as defensive action
>>
>>>> Switch to sock_error() which atomically reads and clears sk->sk_err,
>>>> so the error is consumed when returned.
>>>>
>>>> Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com>
>>>> Reported-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com
>>>
>>> Can you explain how this patch fixes that issue?
>>> (this should be the first information to be put in the commit message
>>> IMHO)
>>>
>>> I'd like to understand better if this is a fix of real bug or just an
>>> improvement to the code (which is fine by me).
>>>
>>> Thanks,
>>> Stefano
>>>
>> Here are the steps of the syzkaller reproducer:
>>
>> r0 = socket(AF_VSOCK, SOCK_STREAM, 0)
>>
>> bind(r0, {VMADDR_CID_ANY, PORT})
>>
>> connect(r0, {VMADDR_CID_LOCAL, PORT})
>>
>> listen(r0, backlog)
>>
>> r1 = socket(AF_VSOCK, SOCK_STREAM, 0)
>>
>> connect(r1, {VMADDR_CID_LOCAL, PORT})
>>
>> connect(r0 -> self) -> -1, EPROTO
>>
>> listen(r0) -> 0
>>
>> connect(r1 -> r0) -> 0
>>
>> accept(r0) -> -1, EPROTO
>>
>> Basically, it creates a socket (r0) and triggers a self-connect after
>> binding it. This self-connect fails with EPROTO because it loops back
>> to r0 while the socket is still in the TCP_SYN_SENT state, causing it
>> to be incorrectly dispatched to the connecting-client path. The
>> unexpected packet type encountered there sets sk_err to EPROTO.
>>
>> After that, it invokes a listen() call on the same socket. This
>> listen() call succeeds because the kernel's listening path never
>> inspects or clears sk_err. Then, a new socket (r1) is created as a
>> normal client and connects to r0. However, vsock_accept() rejects this
>> incoming connection because the listener's sk_err still holds the
>> EPROTO error from the earlier failed self-connect.
>>
>> This rejection causes the child socket created for r1's connection to
>> never be freed on virtio or hyperv transports; only the VMCI transport
>> implements pending_work to revisit and clean up a rejected socket
>> This patch will prevent the rejection branch to occur in this scenario.
>
> Okay, get it now, thanks! Please include a summary of this in the commit
> description.
>
> I understand that this resolves syzbot's specific test case, but it
> would be best to handle rejected sockets more effectively in af_vsock.c
> rather than in the transport layers (if possible). In any case, this can
> be done in another patch.
>
>>
>> I think we might schedule the cleanup worker to run in the rejection
>> path for these transports as well.
>
> Yeah, we need to handle that part better, I think it's a leftover when
> we generalized AF_VSOCK to support more transport than vmci.
>
> Indeed this part is a bit confusing:
>
> /* If the listener socket has received an error, then we should
> * reject this socket and return. Note that we simply mark the
> * socket rejected, drop our reference, and let the cleanup
> * function handle the cleanup; the fact that we found it in
> * the listener's accept queue guarantees that the cleanup
> * function hasn't run yet.
> */
> if (err) {
> vconnected->rejected = true;
> } else {
>
>
> Would be nice to handle everything in af_vsock.c in some way.
>
> In conclusion, the patch LGTM, but please expand the commit description,
> add the Fixes tag, and target the net tree in the v2.
I'll send a v2 with an expanded commit description and the Fixes tag.
Regarding the rejected socket cleanup, I agree it would be cleaner to
handle it entirely in af_vsock.c. I'll look at that as a follow-up.
Thanks,
Phi
^ permalink raw reply
* Re: [PATCH v3] mm/page_reporting: use system_freezable_wq to fix UAF during suspend
From: Link Lin @ 2026-07-23 4:07 UTC (permalink / raw)
To: Andrew Morton
Cc: Vlastimil Babka, Michael S . Tsirkin, David Hildenbrand,
virtualization, linux-mm, linux-kernel, prasin, rientjes, duenwen,
jasowang, xuanzhuo, Ammar Faizi, jiaqiyan, ahwilkins, Greg Thelen,
Alexander Duyck, jthoughton, stable
In-Reply-To: <20260722173639.34d3f58413354218b24a5b0d@linux-foundation.org>
On Tue, Jul 21, 2026 at 5:36 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> hm, now where did that come from. I can find no such commit and that's
> the second time this very unusual thing has happened in 30 minutes! I
> wonder what's going on.
>
> I'll use
> 36e66c554b5c ("mm: introduce Reported pages")
> OK?
Yes, that Fixes tag is perfectly OK. I pulled the previous hash from
an internal downstream tree by mistake. Thank you for catching that
and correcting it!
> The bug is very old so I won't fast-track this fix into 7.2-rcX.
Completely understood and agreed.
> AI review pointed at a possible pre-existing use-after-free issue,
> related to virtio-balloon. But I think this is a rephrasing of the
> issue it flagged against your v2 patch.
I actually looked closely at Sashiko's flag, and to my surprise, it is not a
rephrasing—it caught a completely separate, valid edge case.
My patch fixes the UAF on the PM suspend/teardown path. However, Sashiko noticed
a UAF on the PM *restore* error path. If virtballoon_restore() fails during
init_vqs(), it aborts without unregistering the page reporting worker. When
system_freezable_wq thaws, the reporting worker wakes up and dereferences the
now-dangling vb->reporting_vq pointer.
Since it's a driver-specific lifecycle bug rather than a core MM workqueue
issue, I will write up a separate follow-up patch to address it in
virtio_balloon.c
shortly.
Thank you again for shepherding this fix into -mm!
Best,
Link
^ permalink raw reply
* [PATCH v2 2/3] iommu/virtio: Handle iommu_device_register() failures
From: Weimin Xiong @ 2026-07-23 1:54 UTC (permalink / raw)
To: Jean-Philippe Brucker, Joerg Roedel, Will Deacon
Cc: Xiong Weimin, Robin Murphy, virtualization, iommu, linux-kernel
In-Reply-To: <20260716012157.88769-2-xiongwm2026@163.com>
From: Xiong Weimin <xiongweimin@kylinos.cn>
From: Xiong Weimin <xiongweimin@kylinos.cn>
iommu_device_register() returns an error when the IOMMU core fails to
register the hardware instance or probe the buses. viommu_probe()
currently ignores that error and continues as if the device was
registered successfully.
Propagate the failure and unwind the sysfs entry and virtqueues that
were set up earlier. Clear the driver data on the error path as well,
since it is set before registration so bus probing can find the
virtio-IOMMU instance.
Reviewed-by: Will Deacon <will@kernel.org>
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
drivers/iommu/virtio-iommu.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 587fc1319..fb19d0bf4 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -1234,9 +1234,11 @@ static int viommu_probe(struct virtio_device *vdev)
if (ret)
goto err_free_vqs;
- vdev->priv = viommu;
-
- iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
+ ret = iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
+ if (ret)
+ goto err_free_sysfs;
dev_info(dev, "input address: %u bits\n",
order_base_2(viommu->geometry.aperture_end));
@@ -1244,8 +1246,12 @@ static int viommu_probe(struct virtio_device *vdev)
return 0;
+err_free_sysfs:
+ iommu_device_sysfs_remove(&viommu->iommu);
err_free_vqs:
vdev->config->del_vqs(vdev);
+err_clear_priv:
+ vdev->priv = NULL;
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/3] iommu/virtio: Probe error handling and event buffer validation
From: Weimin Xiong @ 2026-07-23 1:54 UTC (permalink / raw)
To: Jean-Philippe Brucker, Joerg Roedel, Will Deacon
Cc: Xiong Weimin, Robin Murphy, virtualization, iommu, linux-kernel
In-Reply-To: <20260716012157.88769-2-xiongwm2026@163.com>
From: Xiong Weimin <xiongweimin@kylinos.cn>
On Thu, Jul 16, 2026 at 09:21:57AM +0800, Will Deacon wrote:
> It's really hard to keep track of all the patches you have on the list.
> Some of them are grouped in a series [1] with a dependency on another
> unmerged patch, others are in-reply to unordered patches [2], nothing is
> versioned and there are unlinked reply-to messages asking us to ignore
> things [3].
>
> Please can you group all related changes into a series, with a cover
> letter and then use versioning so that it's clear which is the latest
> revision?
I apologize for the confusion. I've now combined all related virtio-iommu
fixes into this single v2 series with a proper cover letter.
I've also addressed Sashiko's comments on the error handling in
viommu_probe() [4] - the v2 series sets vdev->priv early before creating
virtqueues and properly unwinds all resources on failure.
This series contains three fixes:
1. Set driver data before enabling virtqueues
- Store vdev->priv before creating virtqueues so that the event virtqueue
callback always sees initialized driver state when the device is made
ready.
2. Handle iommu_device_register() failures
- Properly propagate errors from iommu_device_register() and unwind sysfs
entries, virtqueues, and driver data on failure.
3. Reject short event buffers
- Check for exact buffer size match (len != sizeof(*evt)) instead of just
rejecting oversized buffers (len > sizeof(*evt)).
Changes in v2:
- Combined all three fixes into a single series with cover letter
- Reordered patches to reflect dependencies
- Added err_clear_priv label for early error paths
Xiong Weimin (3):
iommu/virtio: Set driver data before enabling virtqueues
iommu/virtio: Handle iommu_device_register() failures
iommu/virtio: Reject short event buffers
drivers/iommu/virtio-iommu.c | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
--
2.43.0
From: Xiong Weimin <xiongweimin@kylinos.cn>
To: Jean-Philippe Brucker <jpb@kernel.org>,
Joerg Roedel <joro@8bytes.org>,
Will Deacon <will@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>,
virtualization@lists.linux.dev,
iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: [PATCH v2 1/3] iommu/virtio: Set driver data before enabling virtqueues
Date: Thu, 23 Jul 2026 09:51:01 +0800
Message-ID: <20260723095101.1-xiongweimin@kylinos.cn>
References: <20260716012157.88769-2-xiongwm2026@163.com>
In-Reply-To: <20260716012157.88769-2-xiongwm2026@163.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Xiong Weimin <xiongweimin@kylinos.cn>
The event virtqueue callback retrieves the driver state through
vq->vdev->priv. viommu_probe() currently initializes that pointer only
after virtio_device_ready() and after the event queue is populated.
Store the driver data before creating the virtqueues so callbacks always
see initialized driver state once the device is made ready. Clear the
pointer again on probe failure.
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
drivers/iommu/virtio-iommu.c | 14 ++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 587fc1319..fb19d0bf4 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -1169,11 +1169,12 @@ static int viommu_probe(struct virtio_device *vdev)
ida_init(&viommu->domain_ids);
viommu->dev = dev;
viommu->vdev = vdev;
+ vdev->priv = viommu;
INIT_LIST_HEAD(&viommu->requests);
ret = viommu_init_vqs(viommu);
if (ret)
- return ret;
+ goto err_clear_priv;
virtio_cread_le(vdev, struct virtio_iommu_config, page_size_mask,
&viommu->pgsize_bitmap);
@@ -1234,9 +1235,9 @@ static int viommu_probe(struct virtio_device *vdev)
if (ret)
goto err_free_vqs;
- vdev->priv = viommu;
-
- iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
+ ret = iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
+ if (ret)
+ goto err_free_sysfs;
dev_info(dev, "input address: %u bits\n",
order_base_2(viommu->geometry.aperture_end));
@@ -1244,8 +1245,12 @@ static int viommu_probe(struct virtio_device *vdev)
return 0;
+err_free_sysfs:
+ iommu_device_sysfs_remove(&viommu->iommu);
err_free_vqs:
vdev->config->del_vqs(vdev);
+err_clear_priv:
+ vdev->priv = NULL;
return ret;
}
--
2.43.0
From: Xiong Weimin <xiongweimin@kylinos.cn>
To: Jean-Philippe Brucker <jpb@kernel.org>,
Joerg Roedel <joro@8bytes.org>,
Will Deacon <will@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>,
virtualization@lists.linux.dev,
iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: [PATCH v2 2/3] iommu/virtio: Handle iommu_device_register() failures
Date: Thu, 23 Jul 2026 09:51:02 +0800
Message-ID: <20260723095102.1-xiongweimin@kylinos.cn>
References: <20260716012157.88769-2-xiongwm2026@163.com>
In-Reply-To: <20260716012157.88769-2-xiongwm2026@163.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Xiong Weimin <xiongweimin@kylinos.cn>
iommu_device_register() returns an error when the IOMMU core fails to
register the hardware instance or probe the buses. viommu_probe()
currently ignores that error and continues as if the device was
registered successfully.
Propagate the failure and unwind the sysfs entry and virtqueues that
were set up earlier. Clear the driver data on the error path as well,
since it is set before registration so bus probing can find the
virtio-IOMMU instance.
Reviewed-by: Will Deacon <will@kernel.org>
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
drivers/iommu/virtio-iommu.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 587fc1319..fb19d0bf4 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -1234,9 +1234,11 @@ static int viommu_probe(struct virtio_device *vdev)
if (ret)
goto err_free_vqs;
- vdev->priv = viommu;
-
- iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
+ ret = iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
+ if (ret)
+ goto err_free_sysfs;
dev_info(dev, "input address: %u bits\n",
order_base_2(viommu->geometry.aperture_end));
@@ -1244,8 +1246,12 @@ static int viommu_probe(struct virtio_device *vdev)
return 0;
+err_free_sysfs:
+ iommu_device_sysfs_remove(&viommu->iommu);
err_free_vqs:
vdev->config->del_vqs(vdev);
+err_clear_priv:
+ vdev->priv = NULL;
return ret;
}
--
2.43.0
From: Xiong Weimin <xiongweimin@kylinos.cn>
To: Jean-Philippe Brucker <jpb@kernel.org>,
Joerg Roedel <joro@8bytes.org>,
Will Deacon <will@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>,
virtualization@lists.linux.dev,
iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: [PATCH v2 3/3] iommu/virtio: Reject short event buffers
Date: Thu, 23 Jul 2026 09:51:03 +0800
Message-ID: <20260723095103.1-xiongweimin@kylinos.cn>
References: <20260716012157.88769-2-xiongwm2026@163.com>
In-Reply-To: <20260716012157.88769-2-xiongwm2026@163.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Xiong Weimin <xiongweimin@kylinos.cn>
viommu_event_handler() only rejects event buffers that are larger than
struct viommu_event. A short buffer is also invalid, but the handler
would still read evt->head and, for fault events, the rest of evt->fault.
Require the used length to match the event buffer size before looking at
the event contents.
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
drivers/iommu/virtio-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 587fc1319..fb19d0bf4 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -635,7 +635,7 @@ static void viommu_event_handler(struct virtqueue *vq)
struct viommu_dev *viommu = vq->vdev->priv;
while ((evt = virtqueue_get_buf(vq, &len)) != NULL) {
- if (len > sizeof(*evt)) {
+ if (len != sizeof(*evt)) {
dev_err(viommu->dev,
"invalid event buffer (len %u != %zu)\n",
len, sizeof(*evt));
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/3] iommu/virtio: Set driver data before enabling virtqueues
From: Weimin Xiong @ 2026-07-23 1:54 UTC (permalink / raw)
To: Jean-Philippe Brucker, Joerg Roedel, Will Deacon
Cc: Xiong Weimin, Robin Murphy, virtualization, iommu, linux-kernel
In-Reply-To: <20260716012157.88769-2-xiongwm2026@163.com>
From: Xiong Weimin <xiongweimin@kylinos.cn>
From: Xiong Weimin <xiongweimin@kylinos.cn>
The event virtqueue callback retrieves the driver state through
vq->vdev->priv. viommu_probe() currently initializes that pointer only
after virtio_device_ready() and after the event queue is populated.
Store the driver data before creating the virtqueues so callbacks always
see initialized driver state once the device is made ready. Clear the
pointer again on probe failure.
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
drivers/iommu/virtio-iommu.c | 14 ++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 587fc1319..fb19d0bf4 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -1169,11 +1169,12 @@ static int viommu_probe(struct virtio_device *vdev)
ida_init(&viommu->domain_ids);
viommu->dev = dev;
viommu->vdev = vdev;
+ vdev->priv = viommu;
INIT_LIST_HEAD(&viommu->requests);
ret = viommu_init_vqs(viommu);
if (ret)
- return ret;
+ goto err_clear_priv;
virtio_cread_le(vdev, struct virtio_iommu_config, page_size_mask,
&viommu->pgsize_bitmap);
@@ -1234,9 +1235,9 @@ static int viommu_probe(struct virtio_device *vdev)
if (ret)
goto err_free_vqs;
- vdev->priv = viommu;
-
- iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
+ ret = iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
+ if (ret)
+ goto err_free_sysfs;
dev_info(dev, "input address: %u bits\n",
order_base_2(viommu->geometry.aperture_end));
@@ -1244,8 +1245,12 @@ static int viommu_probe(struct virtio_device *vdev)
return 0;
+err_free_sysfs:
+ iommu_device_sysfs_remove(&viommu->iommu);
err_free_vqs:
vdev->config->del_vqs(vdev);
+err_clear_priv:
+ vdev->priv = NULL;
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/3] iommu/virtio: Reject short event buffers
From: Weimin Xiong @ 2026-07-23 1:54 UTC (permalink / raw)
To: Jean-Philippe Brucker, Joerg Roedel, Will Deacon
Cc: Xiong Weimin, Robin Murphy, virtualization, iommu, linux-kernel
In-Reply-To: <20260716012157.88769-2-xiongwm2026@163.com>
From: Xiong Weimin <xiongweimin@kylinos.cn>
From: Xiong Weimin <xiongweimin@kylinos.cn>
viommu_event_handler() only rejects event buffers that are larger than
struct viommu_event. A short buffer is also invalid, but the handler
would still read evt->head and, for fault events, the rest of evt->fault.
Require the used length to match the event buffer size before looking at
the event contents.
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
drivers/iommu/virtio-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 587fc1319..fb19d0bf4 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -635,7 +635,7 @@ static void viommu_event_handler(struct virtqueue *vq)
struct viommu_dev *viommu = vq->vdev->priv;
while ((evt = virtqueue_get_buf(vq, &len)) != NULL) {
- if (len > sizeof(*evt)) {
+ if (len != sizeof(*evt)) {
dev_err(viommu->dev,
"invalid event buffer (len %u != %zu)\n",
len, sizeof(*evt));
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3] mm/page_reporting: use system_freezable_wq to fix UAF during suspend
From: Andrew Morton @ 2026-07-23 0:36 UTC (permalink / raw)
To: Link Lin
Cc: Vlastimil Babka, Michael S . Tsirkin, David Hildenbrand,
virtualization, linux-mm, linux-kernel, prasin, rientjes, duenwen,
jasowang, xuanzhuo, Ammar Faizi, jiaqiyan, ahwilkins, Greg Thelen,
Alexander Duyck, jthoughton, stable
In-Reply-To: <20260721005603.1710551-1-linkl@google.com>
On Tue, 21 Jul 2026 00:55:33 +0000 Link Lin <linkl@google.com> wrote:
> During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like
> virtio_balloon reset their underlying virtio devices and delete their
> virtqueues via vdev->config->del_vqs().
>
> ...
>
> Fix this by switching page reporting work to system_freezable_wq.
>
> ...
>
Thanks.
> Fixes: 924a663f75e2 ("virtio-balloon: Reporting free page reservations")
hm, now where did that come from. I can find no such commit and that's
the second time this very unusual thing has happened in 30 minutes! I
wonder what's going on.
I'll use
36e66c554b5c ("mm: introduce Reported pages")
OK?
> Cc: stable@vger.kernel.org
The bug is very old so I won't fast-track this fix into 7.2-rcX.
AI review pointed at a possible pre-existing use-after-free issue,
related to virtio-balloon. But I think this is a rephrasing of the
issue it flagged against your v2 patch.
https://sashiko.dev/#/patchset/20260721005603.1710551-1-linkl@google.com
^ permalink raw reply
* Re: [PATCH] iommu/virtio: Handle iommu_device_register() failures
From: Will Deacon @ 2026-07-22 21:42 UTC (permalink / raw)
To: Weimin Xiong; +Cc: virtualization, iommu, jpb, joro, robin.murphy, linux-kernel
In-Reply-To: <20260716012157.88769-2-xiongwm2026@163.com>
On Thu, Jul 16, 2026 at 09:21:57AM +0800, Weimin Xiong wrote:
> From: Xiong Weimin <xiongweimin@kylinos.cn>
>
> iommu_device_register() returns an error when the IOMMU core fails to
> register the hardware instance or probe the buses. viommu_probe()
> currently ignores that error and continues as if the device was
> registered successfully.
>
> Propagate the failure and unwind the sysfs entry and virtqueues that
> were set up earlier. Clear the driver data on the error path as well,
> since it is set before registration so bus probing can find the
> virtio-IOMMU instance.
>
> Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
> ---
> drivers/iommu/virtio-iommu.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
It's really hard to keep track of all the patches you have on the list.
Some of them are grouped in a series [1] with a dependency on another
unmerged patch, others are in-reply to unordered patches [2], nothing is
versioned and there are unlinked reply-to messages asking us to ignore
things [3].
Please can you group all related changes into a series, with a cover
letter and then use versioning so that it's clear which is the latest
revision?
As an aside, Sashiko has lots of comments about the error handling in
the virtio IOMMU probe:
https://sashiko.dev/#/patchset/20260716012157.88769-2-xiongwm2026@163.com
Will
[1] https://lore.kernel.org/all/20260714025914.193580-1-15927021679@163.com/
[2] https://lore.kernel.org/all/20260716012157.88769-2-xiongwm2026@163.com/
[3] https://lore.kernel.org/all/20260716012513.89178-1-xiongwm2026@163.com/
^ permalink raw reply
* Re: [PATCH v1 1/2] iommu/virtio: Set driver data before enabling virtqueues
From: Will Deacon @ 2026-07-22 21:42 UTC (permalink / raw)
To: weimin xiong
Cc: Jean-Philippe Brucker, Joerg Roedel, Robin Murphy, virtualization,
iommu, linux-kernel, Xiong Weimin
In-Reply-To: <20260714025914.193580-2-15927021679@163.com>
On Tue, Jul 14, 2026 at 10:59:13AM +0800, weimin xiong wrote:
> From: Xiong Weimin <xiongweimin@kylinos.cn>
>
> The event virtqueue callback retrieves the driver state through
> vq->vdev->priv. viommu_probe() currently initializes that pointer only
> after virtio_device_ready() and after the event queue is populated.
>
> Store the driver data before creating the virtqueues so callbacks always
> see initialized driver state once the device is made ready. Clear the
> pointer again on probe failure.
>
> Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
> ---
> drivers/iommu/virtio-iommu.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
> index 9118377d7..4c91a82d2 100644
> --- a/drivers/iommu/virtio-iommu.c
> +++ b/drivers/iommu/virtio-iommu.c
> @@ -1173,11 +1173,12 @@ static int viommu_probe(struct virtio_device *vdev)
> ida_init(&viommu->domain_ids);
> viommu->dev = dev;
> viommu->vdev = vdev;
> + vdev->priv = viommu;
> INIT_LIST_HEAD(&viommu->requests);
>
> ret = viommu_init_vqs(viommu);
> if (ret)
> - return ret;
> + goto err_clear_priv;
I guess it would make sense to pass the 'vdev' instead of the 'viommu'
pointer to viommu_init_vqs(), now that you have linked them together.
Will
^ permalink raw reply
* Re: [PATCH v1 2/2] iommu/virtio: Reject short event buffers
From: Will Deacon @ 2026-07-22 21:41 UTC (permalink / raw)
To: weimin xiong
Cc: Jean-Philippe Brucker, Joerg Roedel, Robin Murphy, virtualization,
iommu, linux-kernel, Xiong Weimin
In-Reply-To: <20260714025914.193580-3-15927021679@163.com>
On Tue, Jul 14, 2026 at 10:59:14AM +0800, weimin xiong wrote:
> From: Xiong Weimin <xiongweimin@kylinos.cn>
>
> viommu_event_handler() only rejects event buffers that are larger than
> struct viommu_event. A short buffer is also invalid, but the handler
> would still read evt->head and, for fault events, the rest of evt->fault.
>
> Require the used length to match the event buffer size before looking at
> the event contents.
>
> Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
> ---
> drivers/iommu/virtio-iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
> index 4c91a82d2..4b7f0dcfa 100644
> --- a/drivers/iommu/virtio-iommu.c
> +++ b/drivers/iommu/virtio-iommu.c
> @@ -635,7 +635,7 @@ static void viommu_event_handler(struct virtqueue *vq)
> struct viommu_dev *viommu = vq->vdev->priv;
>
> while ((evt = virtqueue_get_buf(vq, &len)) != NULL) {
> - if (len > sizeof(*evt)) {
> + if (len != sizeof(*evt)) {
> dev_err(viommu->dev,
> "invalid event buffer (len %u != %zu)\n",
> len, sizeof(*evt));
See Jean-Phillipe's previous reply to an identical patch:
https://lore.kernel.org/all/6800BE0812AF0897+20260706083148.788991-1-raoxu@uniontech.com/
Will
^ permalink raw reply
* Re: [PATCH] vhost-scsi: flush backend after device ioctls
From: Mike Christie @ 2026-07-22 17:17 UTC (permalink / raw)
To: Jia Jia, Michael S . Tsirkin, Jason Wang
Cc: Paolo Bonzini, Stefan Hajnoci, Eugenio Pérez, virtualization,
kvm, netdev
In-Reply-To: <20260721073639.1532488-1-physicalmtea@gmail.com>
On 7/21/26 2:36 AM, Jia Jia wrote:
> vhost-scsi translates guest response descriptors into userspace iovecs
> at command submission time and later completes those commands
> asynchronously through target-core. Device-wide control operations such
> as VHOST_SET_MEM_TABLE replace the memory table under the device and
> virtqueue mutexes, but historically returned without waiting for
> outstanding SCSI commands that still hold the pre-update response
> iovecs.
>
> After such a replacement, completion may write virtio_scsi_cmd_resp
> through the old host virtual addresses. If the owner has already
> remapped those addresses, the write lands on the wrong userspace object.
> The kernel tree has carried a TODO for this since the 2012 split of
> vhost_dev_ioctl() and vhost_vring_ioctl():
>
> /* TODO: flush backend after dev ioctl. */
>
> A userspace test kept a READ(10) pending, replaced the memory table so
> the response GPA mapped to a new HVA, remapped the old response address
> as a victim page, and then let the command complete. The completion
> wrote the victim page (victim_changed=yes) and left the replacement
> page unchanged; a later TUR updated the new mapping instead. So the
> pending command retained the pre-update response address across
> VHOST_SET_MEM_TABLE.
>
> That same 2012 change deliberately avoided a second backend flush on the
> vring-ioctl path: vring updates already flush where appropriate, and an
> extra heavy flush would hurt when kick or call fds are reconfigured on
> the data path. This fix does not reintroduce that. The default branch
> still routes unknown commands through vhost_dev_ioctl() first; only a
> non-ENOIOCTLCMD result flushes. Vring ops such as SET_VRING_KICK/CALL,
> num, addr, and base return -ENOIOCTLCMD there and fall through to
> vhost_vring_ioctl() without this backend flush.
>
> What vhost_dev_ioctl() actually handles on this path is small:
> VHOST_SET_OWNER, VHOST_SET_MEM_TABLE, VHOST_SET_LOG_BASE,
> VHOST_SET_LOG_FD, and the optional fork-owner ioctls when enabled.
> Flushing after those is fine: they are rare device-wide control ops,
> and SET_OWNER normally runs before any inflight SCSI work. Call
> vhost_scsi_flush() so pre-update worker work and target-core inflight
> commands finish before the ioctl returns. As with the existing net
> pattern, any non-ENOIOCTLCMD result flushes, including failures that
> may have applied a partial update such as VHOST_SET_LOG_BASE.
>
> I later noticed vhost-net and vhost-vsock already use the same device
> versus vring split.
>
> This is a control-plane barrier only. Ordinary submission, completion,
> kick, and call paths are unchanged. The owner is expected to keep
> pre-update mappings valid until the device ioctl returns. Completion
> copies the response and signals from the vhost worker without needing
> further userspace progress, so waiting in this ioctl does not leave the
> owner process stuck on itself.
It's such a long and verbose description. Was it written by AI? Was the
patch also done with AI?
>
> Signed-off-by: Jia Jia <physicalmtea@gmail.com>
> ---
> drivers/vhost/scsi.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
> index 9a1253b9d8c5..c3e8f1a0b2d4 100644
> --- a/drivers/vhost/scsi.c
> +++ b/drivers/vhost/scsi.c
> @@ -2424,10 +2424,11 @@ vhost_scsi_ioctl(struct file *f, unsigned int ioctl, unsigned long arg)
> default:
> mutex_lock(&vs->dev.mutex);
> r = vhost_dev_ioctl(&vs->dev, ioctl, argp);
> - /* TODO: flush backend after dev ioctl. */
> if (r == -ENOIOCTLCMD)
> r = vhost_vring_ioctl(&vs->dev, ioctl, argp);
> + else
Is it still possible for userspace to execute the READ/TUR sequence
describe above at this time before the flush?
From the description it sounded like we needed to stop new cmds, flush
running cmds, swap the new mem pointer, then start new commands?
> + vhost_scsi_flush(vs);
> mutex_unlock(&vs->dev.mutex);
> return r;
^ permalink raw reply
* Re: [PATCH v2 13/13] mm/mremap: convert mremap code to use vma_flags_t
From: Vlastimil Babka (SUSE) @ 2026-07-22 16:15 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-13-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Replace use of the legacy vm_flags_t flags with vma_flags_t values
> throughout the mremap logic.
>
> Note that, in replacing vm_flags_clear() (which takes the VMA write lock)
> with vma_clear_flags() and vma_clear_flags_mask() (which do not)
> respectively in unmap_source_vma() and dontunmap_complete(), we do not add
> a VMA write lock to account for htis.
>
> This is because, in both cases, move_vma() is their calling function and
> this has already acquired the VMA write lock on vrm->vma whose VMA flags
> are being cleared.
>
> In the case of vma_set_flags() in unmap_source_vma() we do need to do this
> - as prev and next were not necessarily write locked at this point.
>
> Additionally update comments to reflect the changes to be consistent.
>
> No functional change intended.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 12/13] mm/mprotect: convert mprotect code to use vma_flags_t
From: Vlastimil Babka (SUSE) @ 2026-07-22 16:09 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-12-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Replace use of the legacy vm_flags_t flags with vma_flags_t values
> throughout the mprotect logic.
>
> Note that we retain the legacy vm_flags_t bit shifting code in
> do_mprotect_pkey(), deferring a vma_flags_t approach to this for the time
> being.
>
> Additionally update comments to reflect the changes to be consistent.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 11/13] mm/mlock: convert mlock code to use vma_flags_t
From: Vlastimil Babka (SUSE) @ 2026-07-22 16:07 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-11-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Replace use of the legacy vm_flags_t flags with vma_flags_t values
> throughout the mlock logic.
>
> Additionally update comments to reflect the changes to be consistent.
>
> No functional change intended.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 10/13] mm/vma: convert miscellaneous uses of VMA flags in core mm
From: Vlastimil Babka (SUSE) @ 2026-07-22 16:04 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-10-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Update various uses of legacy flags in vma.c and mmap.c to the new
> vma_flags_t type, updating comments alongside them to be consistent.
>
> No functional change intended.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 09/13] mm/vma: update create_init_stack_vma() to use vma_flags_t
From: Vlastimil Babka (SUSE) @ 2026-07-22 15:52 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-9-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Replace use of the legacy vm_flags_t flags with vma_flags_t values in
> create_init_stack_vma().
>
> As part of this change we add VMA_STACK_EARLY and VMA_STACK_INCOMPLETE
> vma_flags_t defines, and slightly rework create_init_stack_vma() for
> clarity.
>
> No functional change intended.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH] virtio: rtc: time out alarm requests
From: Peter Hilber @ 2026-07-22 15:48 UTC (permalink / raw)
To: GuoHan Zhao
Cc: Michael S. Tsirkin, virtualization, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Alexandre Belloni, linux-kernel
In-Reply-To: <20260714024352.71307-1-zhaoguohan@kylinos.cn>
On Tue, Jul 14, 2026 at 10:43:52AM +0800, GuoHan Zhao wrote:
> RTC class operations run with rtc_device.ops_lock held. The virtio RTC
> alarm requests currently wait without a timeout for the device to return
> their requestq buffers.
>
> On surprise removal, virtio-pci marks the virtqueues broken before
> unregistering the virtio device. If an alarm request is waiting when the
> device stops responding, viortc_remove() blocks in viortc_class_stop()
> while trying to acquire ops_lock. The request cannot complete and device
> removal hangs until the waiting task is signalled.
>
> Use the same 60-second timeout as clock read requests for alarm reads,
> alarm programming, and alarm interrupt enable requests. The existing
> message reference counting keeps a timed-out request alive until a late
> response or device teardown.
>
> Fixes: 9d4f22fd563e ("virtio_rtc: Add RTC class driver")
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: GuoHan Zhao <zhaoguohan@kylinos.cn>
Thanks for the fix!
Reviewed-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 08/13] mm: introduce vma_get_page_prot() and use it
From: Vlastimil Babka (SUSE) @ 2026-07-22 15:42 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-sound, Jani Nikula
In-Reply-To: <20260711-b4-vma-flags-mm-v2-8-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> There's a large number of vm_get_page_prot(vma->vm_flags) invocations. Make
> life easier by introducing vma_get_page_prot() parameterised by the VMA.
>
> This also makes converting vm_get_page_prot() to vma_flags_t easier.
>
> Also update the userland VMA tests to reflect the change.
>
> No functional change intended.
>
> Acked-by: Zi Yan <ziy@nvidia.com>
> Acked-by: Jani Nikula <jani.nikula@intel.com> # for i915
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> # for DRM
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH] vhost-scsi: fix T10-PI lifecycle hard BUG after endpoint
From: Stefan Hajnoczi @ 2026-07-22 15:14 UTC (permalink / raw)
To: Jia Jia
Cc: mst, jasowangio, michael.christie, pbonzini, stefanha, eperezma,
virtualization, linux-kernel
In-Reply-To: <20260722063609.1546421-1-physicalmtea@gmail.com>
On Wed, Jul 22, 2026 at 2:40 AM Jia Jia <physicalmtea@gmail.com> wrote:
>
> vhost_scsi_setup_vq_cmds() runs only from VHOST_SCSI_SET_ENDPOINT and
> allocates each command's protection scatterlist array (prot_sgl) only
> when VIRTIO_SCSI_F_T10_PI is already set at that moment. Command pools
> are not rebuilt later. vhost_scsi_set_features() may still flip that
> bit after the endpoint is live: it updates acked_features and returns
> success without reallocating prot_sgl.
>
> That is a feature-versus-resource lifetime mismatch. The broken order
> is:
>
> VHOST_SET_FEATURES(0)
> VHOST_SCSI_SET_ENDPOINT
> setup_vq_cmds() sees no T10-PI -> prot_sgl stays NULL
> VHOST_SET_FEATURES(VIRTIO_SCSI_F_T10_PI)
> only acked_features changes; command resources stay as above
VIRTIO_SCSI_F_T10_PI is defined in the VIRTIO spec. VIRTIO feature
bits do not change once negotiated. The device must be reset in order
to set the feature bits again.
VHOST_F_LOG_ALL is a vhost-specific feature bit that is not covered by
the VIRTIO spec and it can be changed at runtime. It is an exception.
Please generalize this fix to only allow VHOST_F_LOG_ALL to be changed
at runtime. Rather than protecting VIRTIO_SCSI_F_T10_PI specifically,
attempts to change feature bits other than VHOST_F_LOG_ALL once the
device is operational must be rejected.
Perhaps other vhost device implementations have the same issue?
Thanks,
Stefan
> submit a T10-PI WRITE with a 129-page protection payload
>
> The I/O path then follows the new feature bit while using the old
> command objects. vhost_scsi_mapal() (static, inlined into
> vhost_scsi_handle_vq() here) does:
>
> sg_alloc_table_chained(table, 129, first_chunk=NULL,
> nents_first_chunk=inline_sg_cnt)
>
> With first_chunk NULL, __sg_alloc_table() sets curr_max_ents from
> nents_first_chunk and calls sg_pool_alloc(129). sg_pool_index() then
> hits:
>
> BUG_ON(nents > SG_CHUNK_SIZE); /* 129 > 128 */
>
> The kernel reported the following call trace and register state:
>
> Call Trace:
> <TASK>
> ? __sg_alloc_table+0x1d8/0x250
> ? __pfx_vhost_run_work_list+0x10/0x10 [vhost]
> sg_alloc_table_chained+0x59/0xf0
> ? __pfx_sg_pool_alloc+0x10/0x10
> ? vhost_scsi_calc_sgls.constprop.0+0x43/0x60 [vhost_scsi]
> vhost_scsi_handle_vq+0xf02/0x1700 [vhost_scsi]
> ? __pfx_vhost_scsi_handle_vq+0x10/0x10 [vhost_scsi]
> vhost_scsi_handle_kick+0x37/0x50 [vhost_scsi]
> vhost_run_work_list+0x8e/0xd0 [vhost]
> vhost_task_fn+0xe1/0x210
> ret_from_fork+0x348/0x540
> </TASK>
>
> RIP: 0010:0x4
> CR2: 0000000000000004
> RSP: 0018:ffffc90000dbf940 EFLAGS: 00010202
> RAX: ffffffff82396810 RBX: ffff88811dc28b80 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000081
>
> The host worker dies and the machine stops accepting network service
> until reset. The missing object is prot_sgl after a post-endpoint
> T10-PI enable introduced by commit bf2d650391be ("vhost-scsi: Allocate
> T10 PI structs only when enabled").
>
> I also checked the other feature bits handled around endpoint setup.
> Only T10-PI allocates this endpoint-time per-command resource and does
> not rebuild it on a later SET_FEATURES. LOG_ALL uses lazy tvc_log and
> already tears log storage down when cleared; HOTPLUG does not allocate
> prot_sgl. So the chosen fix is to refuse T10-PI enable/disable while
> an endpoint is active, rather than adding a second rebuild path in
> set_features().
>
> Return -EBUSY if vs->vs_tpg is set and the T10-PI bit would change.
> Userspace must CLEAR_ENDPOINT, SET_FEATURES, then SET_ENDPOINT again so
> setup_vq_cmds() can allocate protection SGLs when needed. That matches
> the existing "build command resources at endpoint" model.
>
> Fixes: bf2d650391be ("vhost-scsi: Allocate T10 PI structs only when enabled")
> Signed-off-by: Jia Jia <physicalmtea@gmail.com>
> ---
> drivers/vhost/scsi.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
> index 9a1253b9d8c5..000000000000 100644
> --- a/drivers/vhost/scsi.c
> +++ b/drivers/vhost/scsi.c
> @@ -2219,6 +2219,7 @@ static int vhost_scsi_set_features(struct vhost_scsi *vs, u64 features)
> {
> struct vhost_virtqueue *vq;
> bool is_log, was_log;
> + bool is_t10_pi, was_t10_pi;
> int i;
>
> if (features & ~VHOST_SCSI_FEATURES)
> @@ -2234,6 +2235,13 @@ static int vhost_scsi_set_features(struct vhost_scsi *vs, u64 features)
> if (!vs->dev.nvqs)
> goto out;
>
> + is_t10_pi = features & (1ULL << VIRTIO_SCSI_F_T10_PI);
> + was_t10_pi = vhost_has_feature(&vs->vqs[0].vq, VIRTIO_SCSI_F_T10_PI);
> + if (vs->vs_tpg && is_t10_pi != was_t10_pi) {
> + mutex_unlock(&vs->dev.mutex);
> + return -EBUSY;
> + }
> +
> is_log = features & (1 << VHOST_F_LOG_ALL);
> /*
> * All VQs should have same feature.
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v2 07/13] mm/vma: rename vma_get_page_prot to vma_flags_to_page_prot
From: Vlastimil Babka (SUSE) @ 2026-07-22 14:36 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-7-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Having vma_get_page_prot() refer to VMA flags and vma_set_page_prot() refer
> to a VMA is confusing.
>
> Rename vma_get_page_prot() to vma_flags_to_page_prot() to resolve this
> confusion.
>
> No functional change intended.
>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 06/13] mm/vma: convert vm_pgprot_modify() to use vma_flags_t and rename
From: Vlastimil Babka (SUSE) @ 2026-07-22 14:34 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-6-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Update vm_pgprot_modify() to use the new VMA flags type vma_flags_t, and
> rename to vma_pgprot_modify() accordingly.
>
> This is part of the ongoing work to convert vm_flags_t to vma_flags_t, in
> order to eliminate the arbitrary limit of the number of bits in a system
> word on available VMA flags.
>
> Update VMA userland tests accordingly, updating vma_set_page_prot() to no
> longer inline vma_pgprot_modify(), rather we can simply define
> vma_pgprot_modify() as a static inline function and the tests will pick it
> up from vma.h.
>
> No functional change intended.
>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 05/13] mm: prefer mm->def_vma_flags in mm logic
From: Vlastimil Babka (SUSE) @ 2026-07-22 14:31 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-5-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Currently mm->def_flags (of type vm_flags_t) is union'd with
> mm->def_vma_flags (of type vma_flags_t).
>
> As part of the effort to convert vm_flags_t usage to vma_flags_t (in order
> to no longer be arbitrarily limited to a system word size for VMA flags),
> prefer mm->def_vma_flags to mm->def_flags throughout the mm logic.
>
> We update dump_mm() to use the %*pb format which means we make no
> assumption about the number of VMA flag bits on output when outputting
> default VMA flags.
>
> No functional change intended.
>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> mm/debug.c | 5 +++--
> mm/mlock.c | 13 +++++++------
> mm/mmap.c | 11 ++++++-----
> mm/vma.c | 2 +-
> 4 files changed, 17 insertions(+), 14 deletions(-)
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 04/13] mm: update generic_get_unmapped_area[_topdown]() to use vma_flags_t
From: Vlastimil Babka (SUSE) @ 2026-07-22 14:19 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-4-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> As part of the changes converting VMA flags from a system word size to a
> bitmap, extend this change to generic_get_unmapped_area() and
> generic_get_unmapped_area_topdown(), which also allows us to convert
> stack_guard_placement() as well.
>
> We retain arch_get_unmapped_area() and arch_get_unmapped_area_topdown()
> as-is for now, using legacy_to_vma_flags() as necessary to do so.
>
> No functional change intended.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 03/13] mm: convert __get_unmapped_area() to use vma_flags_t
From: Vlastimil Babka (SUSE) @ 2026-07-22 14:17 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-3-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Update __get_unmapped_area() to be parameterised by vma_flags_t rather than
> vm_flags_t as part of the effort to move VMA flags from a system word to a
> bitmap.
>
> We cascade the changes up to arch_get_unmapped_area_topdown() and
> arch_get_unmapped_area(), where, for now, we use vma_flags_to_legacy() in
> order to propagate the VMA flags.
>
> No functional change intended.
>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ 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