* Re: [PATCH v2] virtio_balloon: prime stats vq after virtio_device_ready()
From: David Hildenbrand (Arm) @ 2026-07-06 8:57 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Adam Litke, Rusty Russell, virtualization, Andrew Morton,
linux-mm
In-Reply-To: <20260706044122-mutt-send-email-mst@kernel.org>
On 7/6/26 10:43, Michael S. Tsirkin wrote:
> On Mon, Jul 06, 2026 at 10:38:18AM +0200, David Hildenbrand (Arm) wrote:
>>>
>>> Yes.
>>>
>>>
>>> Why not?
>>
>> I was wondering whether the spec would state something about that.
>
> Sorry I do not get the question. Virtio API expects
> callers to serialize calls for each VQ. So this just prevents the work
> from running and accessing the VQ while probe calls add_buf/kick.
> I'll add a comment explaining that.
> But it has nothing to do with the spec.
The device is clearly not properly initialized yet.
Yet, we expect that we get a stats_request() callback that would try to
queue_work(). And IIUC, the stats_request() will be directly issued by the device.
In QEMU, that would mean that balloon_stats_poll_cb() runs, which would do a
if (s->stats_vq_elem == NULL) {
...
return
}
virtqueue_push(s->svq, s->stats_vq_elem, 0);
virtio_notify(vdev, s->svq);
That's why I'm confused :)
--
Cheers,
David
^ permalink raw reply
* Re: [syzbot] Monthly virt report (Jun 2026)
From: Stefano Garzarella @ 2026-07-06 9:24 UTC (permalink / raw)
To: mawupeng
Cc: syzbot+listbf7b8eeeb8dda31d6de1, linux-kernel, syzkaller-bugs,
virtualization, mst, jasowang, xuanzhuo, eperezma, stefanha,
davem, edumazet, kuba, pabeni, horms, kvm, netdev
In-Reply-To: <d1e9d389-affa-4d12-aaf7-3fcf3218966c@huawei.com>
On Thu, 2 Jul 2026 at 04:55, mawupeng <mawupeng1@huawei.com> wrote:
> On 周四 2026-6-25 04:32, syzbot wrote:
> > Hello virt maintainers/developers,
> >
> > This is a 31-day syzbot report for the virt subsystem.
> > All related reports/information can be found at:
> > https://syzkaller.appspot.com/upstream/s/virt
> >
> > During the period, 0 new issues were detected and 0 were fixed.
> > In total, 5 issues are still open and 61 have already been fixed.
> > There are also 2 low-priority issues.
> >
> > Some of the still happening issues:
> >
> > Ref Crashes Repro Title
> > <1> 24 No WARNING: refcount bug in call_timer_fn (4)
> > https://syzkaller.appspot.com/bug?extid=07dcf509f4c013e25dc5
> > <2> 3 Yes memory leak in __vsock_create (2)
> > https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
>
> Hi,
>
> This is regarding the still-open "memory leak in __vsock_create (2)"
> bug (#2 in the monthly virt report, extid 1b2c9c4a0f8708082678):
> https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
>
> I spent some time analyzing the root cause and the previous fix
> attempt; below is a summary and a direction that tested out.
[...]
>
> I'm not subscribed to follow the list at full volume; happy to send a
> formal patch (with the af_vsock.h / pending_work changes folded in)
> if the direction looks right to the maintainers.
Yes, please, a formal patch with a great commit message is much better
than a long text to read IMO.
Thanks,
Stefano
^ permalink raw reply
* [RFC/PATCH] vdpa/mlx5: Fix buffer length in create_direct_keys()
From: Christian Borntraeger @ 2026-07-06 10:01 UTC (permalink / raw)
To: Dragos Tatulea
Cc: Michael S . Tsirkin, Jason Wang, virtualization, linux-kernel,
Christian Borntraeger
We have seen in our CI the following KASAN message:
BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core]
Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764
[...]
[<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core]
[<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core]
[<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa]
[<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa]
[...]
The buggy address is located 4128 bytes inside of
allocated 4384-byte region [0000000176794000, 0000000176795120)
So in essence we read 16 bytes beyond 4384-byte allocation.
create_direct_keys calculates the pointer and length for in and out
buffers.
The size calculation for in includes the entire structure
size (out + in + mtt[]) but the pointer passed to cmd_exec points only
to the 'in' field, skipping the 'out' field.
This causes mlx5_copy_to_msg() to read beyond the allocated buffer
by sizeof(out) bytes when copying command data.
Calculates the input size as sizeof(in) + mtt_array_size to match the
pointer and allocation size.
Fixes: 0071b138d44a ("vdpa/mlx5: Create direct MKEYs in parallel")
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
---
drivers/vdpa/mlx5/core/mr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
index 6d02ccf9eb91..03fe7f5ca412 100644
--- a/drivers/vdpa/mlx5/core/mr.c
+++ b/drivers/vdpa/mlx5/core/mr.c
@@ -233,7 +233,7 @@ static int create_direct_keys(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_mr *
cmds[i].out = cmd_mem->out;
cmds[i].outlen = sizeof(cmd_mem->out);
cmds[i].in = cmd_mem->in;
- cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount);
+ cmds[i].inlen = sizeof(cmd_mem->in) + (mttcount * sizeof(cmd_mem->mtt[0]));
fill_create_direct_mr(mvdev, dmr, cmd_mem);
--
2.53.0
^ permalink raw reply related
* Re: [RFC/PATCH] vdpa/mlx5: Fix buffer length in create_direct_keys()
From: Christian Borntraeger @ 2026-07-06 10:13 UTC (permalink / raw)
To: Dragos Tatulea
Cc: Michael S . Tsirkin, Jason Wang, virtualization, linux-kernel
In-Reply-To: <20260706100129.1541140-1-borntraeger@linux.ibm.com>
Am 06.07.26 um 12:01 schrieb Christian Borntraeger:
> We have seen in our CI the following KASAN message:
> BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core]
> Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764
> [...]
> [<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core]
> [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core]
> [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa]
> [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa]
> [...]
> The buggy address is located 4128 bytes inside of
> allocated 4384-byte region [0000000176794000, 0000000176795120)
>
> So in essence we read 16 bytes beyond 4384-byte allocation.
> create_direct_keys calculates the pointer and length for in and out
> buffers.
> The size calculation for in includes the entire structure
> size (out + in + mtt[]) but the pointer passed to cmd_exec points only
> to the 'in' field, skipping the 'out' field.
>
> This causes mlx5_copy_to_msg() to read beyond the allocated buffer
> by sizeof(out) bytes when copying command data.
>
> Calculates the input size as sizeof(in) + mtt_array_size to match the
> pointer and allocation size.
>
> Fixes: 0071b138d44a ("vdpa/mlx5: Create direct MKEYs in parallel")
> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
> ---
> drivers/vdpa/mlx5/core/mr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
> index 6d02ccf9eb91..03fe7f5ca412 100644
> --- a/drivers/vdpa/mlx5/core/mr.c
> +++ b/drivers/vdpa/mlx5/core/mr.c
> @@ -233,7 +233,7 @@ static int create_direct_keys(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_mr *
> cmds[i].out = cmd_mem->out;
> cmds[i].outlen = sizeof(cmd_mem->out);
> cmds[i].in = cmd_mem->in;
> - cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount);
> + cmds[i].inlen = sizeof(cmd_mem->in) + (mttcount * sizeof(cmd_mem->mtt[0]));
Assuming the fix is the correct fix, question is, if I should use the offset of in instead, e.g.
cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount) - offsetof(cmd_mem, in);
to handle potential alignment and padding aspects.
^ permalink raw reply
* Re: [syzbot] Monthly virt report (Jun 2026)
From: mawupeng @ 2026-07-06 11:31 UTC (permalink / raw)
To: sgarzare
Cc: mawupeng1, syzbot+listbf7b8eeeb8dda31d6de1, linux-kernel,
syzkaller-bugs, virtualization, mst, jasowang, xuanzhuo, eperezma,
stefanha, davem, edumazet, kuba, pabeni, horms, kvm, netdev
In-Reply-To: <CAGxU2F582RpWGOUxTU783zZuxWj7e4eZtiDcNdUmWobLSFSq2g@mail.gmail.com>
On 周一 2026-7-6 17:24, Stefano Garzarella wrote:
> On Thu, 2 Jul 2026 at 04:55, mawupeng <mawupeng1@huawei.com> wrote:
>> On 周四 2026-6-25 04:32, syzbot wrote:
>>> Hello virt maintainers/developers,
>>>
>>> This is a 31-day syzbot report for the virt subsystem.
>>> All related reports/information can be found at:
>>> https://syzkaller.appspot.com/upstream/s/virt
>>>
>>> During the period, 0 new issues were detected and 0 were fixed.
>>> In total, 5 issues are still open and 61 have already been fixed.
>>> There are also 2 low-priority issues.
>>>
>>> Some of the still happening issues:
>>>
>>> Ref Crashes Repro Title
>>> <1> 24 No WARNING: refcount bug in call_timer_fn (4)
>>> https://syzkaller.appspot.com/bug?extid=07dcf509f4c013e25dc5
>>> <2> 3 Yes memory leak in __vsock_create (2)
>>> https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
>>
>> Hi,
>>
>> This is regarding the still-open "memory leak in __vsock_create (2)"
>> bug (#2 in the monthly virt report, extid 1b2c9c4a0f8708082678):
>> https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
>>
>> I spent some time analyzing the root cause and the previous fix
>> attempt; below is a summary and a direction that tested out.
>
> [...]
>
>>
>> I'm not subscribed to follow the list at full volume; happy to send a
>> formal patch (with the af_vsock.h / pending_work changes folded in)
>> if the direction looks right to the maintainers.
>
> Yes, please, a formal patch with a great commit message is much better
> than a long text to read IMO.
Thanks for replying.
As we conducted more thorough testing and further analysis of our own fix,
we found that it is not as comprehensive as the existing AI-generated fix
provided[1].
Could you please let us know if there are any issues with this AI-generated fix?
[1]: https://syzkaller.appspot.com/ai_job?id=cd978d21-2110-4f57-9525-d7d91c4a7e02
>
> Thanks,
> Stefano
>
>
^ permalink raw reply
* Re: [syzbot] Monthly virt report (Jun 2026)
From: Aleksandr Nogikh @ 2026-07-06 11:54 UTC (permalink / raw)
To: mawupeng
Cc: sgarzare, syzbot+listbf7b8eeeb8dda31d6de1, linux-kernel,
syzkaller-bugs, virtualization, mst, jasowang, xuanzhuo, eperezma,
stefanha, davem, edumazet, kuba, pabeni, horms, kvm, netdev
In-Reply-To: <0e51efaa-24b7-4a19-97f4-0669fd92d513@huawei.com>
On Mon, Jul 6, 2026 at 1:32 PM 'mawupeng' via syzkaller-bugs
<syzkaller-bugs@googlegroups.com> wrote:
>
>
>
> On 周一 2026-7-6 17:24, Stefano Garzarella wrote:
> > On Thu, 2 Jul 2026 at 04:55, mawupeng <mawupeng1@huawei.com> wrote:
> >> On 周四 2026-6-25 04:32, syzbot wrote:
> >>> Hello virt maintainers/developers,
> >>>
> >>> This is a 31-day syzbot report for the virt subsystem.
> >>> All related reports/information can be found at:
> >>> https://syzkaller.appspot.com/upstream/s/virt
> >>>
> >>> During the period, 0 new issues were detected and 0 were fixed.
> >>> In total, 5 issues are still open and 61 have already been fixed.
> >>> There are also 2 low-priority issues.
> >>>
> >>> Some of the still happening issues:
> >>>
> >>> Ref Crashes Repro Title
> >>> <1> 24 No WARNING: refcount bug in call_timer_fn (4)
> >>> https://syzkaller.appspot.com/bug?extid=07dcf509f4c013e25dc5
> >>> <2> 3 Yes memory leak in __vsock_create (2)
> >>> https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
> >>
> >> Hi,
> >>
> >> This is regarding the still-open "memory leak in __vsock_create (2)"
> >> bug (#2 in the monthly virt report, extid 1b2c9c4a0f8708082678):
> >> https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
> >>
> >> I spent some time analyzing the root cause and the previous fix
> >> attempt; below is a summary and a direction that tested out.
> >
> > [...]
> >
> >>
> >> I'm not subscribed to follow the list at full volume; happy to send a
> >> formal patch (with the af_vsock.h / pending_work changes folded in)
> >> if the direction looks right to the maintainers.
> >
> > Yes, please, a formal patch with a great commit message is much better
> > than a long text to read IMO.
>
> Thanks for replying.
>
> As we conducted more thorough testing and further analysis of our own fix,
> we found that it is not as comprehensive as the existing AI-generated fix
> provided[1].
>
> Could you please let us know if there are any issues with this AI-generated fix?
>
> [1]: https://syzkaller.appspot.com/ai_job?id=cd978d21-2110-4f57-9525-d7d91c4a7e02
I'll chime in from the syzbot side.
If anything is missing, please let us know :)
Otherwise, please note that the bot can incorporate code review notes
and, once the patch is ready, submit it to the LKML:
https://github.com/google/syzkaller/blob/master/docs/syzbot_ai_patches.md
Best Regards,
Aleksandr
>
> >
> > Thanks,
> > Stefano
> >
> >
>
^ permalink raw reply
* Re: [RFC/PATCH] vdpa/mlx5: Fix buffer length in create_direct_keys()
From: Dragos Tatulea @ 2026-07-06 12:24 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Michael S . Tsirkin, Jason Wang, virtualization, linux-kernel
In-Reply-To: <06b371e3-418c-41d8-8c06-1971cc24d8d4@linux.ibm.com>
On 06.07.26 12:13, Christian Borntraeger wrote:
>
>
> Am 06.07.26 um 12:01 schrieb Christian Borntraeger:
>> We have seen in our CI the following KASAN message:
>> BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core]
>> Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764
>> [...]
>> [<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core]
>> [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core]
>> [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa]
>> [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa]
>> [...]
>> The buggy address is located 4128 bytes inside of
>> allocated 4384-byte region [0000000176794000, 0000000176795120)
>>
>> So in essence we read 16 bytes beyond 4384-byte allocation.
>> create_direct_keys calculates the pointer and length for in and out
>> buffers.
>> The size calculation for in includes the entire structure
>> size (out + in + mtt[]) but the pointer passed to cmd_exec points only
>> to the 'in' field, skipping the 'out' field.
>>
>> This causes mlx5_copy_to_msg() to read beyond the allocated buffer
>> by sizeof(out) bytes when copying command data.
>>
>> Calculates the input size as sizeof(in) + mtt_array_size to match the
>> pointer and allocation size.
>>
>> Fixes: 0071b138d44a ("vdpa/mlx5: Create direct MKEYs in parallel")
>> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
>> ---
>> drivers/vdpa/mlx5/core/mr.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
>> index 6d02ccf9eb91..03fe7f5ca412 100644
>> --- a/drivers/vdpa/mlx5/core/mr.c
>> +++ b/drivers/vdpa/mlx5/core/mr.c
>> @@ -233,7 +233,7 @@ static int create_direct_keys(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_mr *
>> cmds[i].out = cmd_mem->out;
>> cmds[i].outlen = sizeof(cmd_mem->out);
>> cmds[i].in = cmd_mem->in;
>> - cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount);
>> + cmds[i].inlen = sizeof(cmd_mem->in) + (mttcount * sizeof(cmd_mem->mtt[0]));
Woops... Thanks for the catch. The fix is good.
>
> Assuming the fix is the correct fix, question is, if I should use the offset of in instead, e.g.
>
> cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount) - offsetof(cmd_mem, in);
>
> to handle potential alignment and padding aspects.
>
Seems harder to read. Why not:
sizeof(cmd_mem->in) + flex_array_size(cmd_mem, mtts, mttcount) ?
Thanks,
Dragos
^ permalink raw reply
* Re: [RFC/PATCH] vdpa/mlx5: Fix buffer length in create_direct_keys()
From: Christian Borntraeger @ 2026-07-06 12:59 UTC (permalink / raw)
To: Dragos Tatulea
Cc: Michael S . Tsirkin, Jason Wang, virtualization, linux-kernel
In-Reply-To: <d7272d8d-8146-4ed0-90d6-2a27eae5ab6e@nvidia.com>
Am 06.07.26 um 14:24 schrieb Dragos Tatulea:
>
>
> On 06.07.26 12:13, Christian Borntraeger wrote:
>>
>>
>> Am 06.07.26 um 12:01 schrieb Christian Borntraeger:
>>> We have seen in our CI the following KASAN message:
>>> BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core]
>>> Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764
>>> [...]
>>> [<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core]
>>> [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core]
>>> [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa]
>>> [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa]
>>> [...]
>>> The buggy address is located 4128 bytes inside of
>>> allocated 4384-byte region [0000000176794000, 0000000176795120)
>>>
>>> So in essence we read 16 bytes beyond 4384-byte allocation.
>>> create_direct_keys calculates the pointer and length for in and out
>>> buffers.
>>> The size calculation for in includes the entire structure
>>> size (out + in + mtt[]) but the pointer passed to cmd_exec points only
>>> to the 'in' field, skipping the 'out' field.
>>>
>>> This causes mlx5_copy_to_msg() to read beyond the allocated buffer
>>> by sizeof(out) bytes when copying command data.
>>>
>>> Calculates the input size as sizeof(in) + mtt_array_size to match the
>>> pointer and allocation size.
>>>
>>> Fixes: 0071b138d44a ("vdpa/mlx5: Create direct MKEYs in parallel")
>>> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
>>> ---
>>> drivers/vdpa/mlx5/core/mr.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
>>> index 6d02ccf9eb91..03fe7f5ca412 100644
>>> --- a/drivers/vdpa/mlx5/core/mr.c
>>> +++ b/drivers/vdpa/mlx5/core/mr.c
>>> @@ -233,7 +233,7 @@ static int create_direct_keys(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_mr *
>>> cmds[i].out = cmd_mem->out;
>>> cmds[i].outlen = sizeof(cmd_mem->out);
>>> cmds[i].in = cmd_mem->in;
>>> - cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount);
>>> + cmds[i].inlen = sizeof(cmd_mem->in) + (mttcount * sizeof(cmd_mem->mtt[0]));
> Woops... Thanks for the catch. The fix is good.
>
>>
>> Assuming the fix is the correct fix, question is, if I should use the offset of in instead, e.g.
>>
>> cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount) - offsetof(cmd_mem, in);
>>
>> to handle potential alignment and padding aspects.
>>
> Seems harder to read. Why not:
> sizeof(cmd_mem->in) + flex_array_size(cmd_mem, mtts, mttcount) ?
Can do that. I assume we do not have any implicit holes in the structure due to alignment? In
other words, sizeof(cmd_mem->in) can never be something like 20 (and then the flex array would
start at 24 to align 8 byte elements). If thats the case I will respin with your proposal.
^ permalink raw reply
* Re: [PATCH v2] virtio_balloon: prime stats vq after virtio_device_ready()
From: Michael S. Tsirkin @ 2026-07-06 12:59 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: linux-kernel, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Adam Litke, Rusty Russell, virtualization, Andrew Morton,
linux-mm
In-Reply-To: <24336f56-1024-4c9b-8653-b1a4658b627c@kernel.org>
On Mon, Jul 06, 2026 at 10:57:33AM +0200, David Hildenbrand (Arm) wrote:
> On 7/6/26 10:43, Michael S. Tsirkin wrote:
> > On Mon, Jul 06, 2026 at 10:38:18AM +0200, David Hildenbrand (Arm) wrote:
> >>>
> >>> Yes.
> >>>
> >>>
> >>> Why not?
> >>
> >> I was wondering whether the spec would state something about that.
> >
> > Sorry I do not get the question. Virtio API expects
> > callers to serialize calls for each VQ. So this just prevents the work
> > from running and accessing the VQ while probe calls add_buf/kick.
> > I'll add a comment explaining that.
> > But it has nothing to do with the spec.
>
> The device is clearly not properly initialized yet.
>
> Yet, we expect that we get a stats_request() callback that would try to
> queue_work(). And IIUC, the stats_request() will be directly issued by the device.
With an in-spec device, it can happen right after virtio_device_ready.
We could defer it a bit, but I don't see what this gets us, and
this also protects against any out of spec ones.
> In QEMU, that would mean that balloon_stats_poll_cb() runs, which would do a
>
> if (s->stats_vq_elem == NULL) {
> ...
> return
> }
>
> virtqueue_push(s->svq, s->stats_vq_elem, 0);
> virtio_notify(vdev, s->svq);
>
>
> That's why I'm confused :)
First the spec says there could be interrupts for no reasons right after
DRIVER_OK. Second there are situations in which qemu might
consume a buffer without a kick and then an interrupt
races with the kick.
> --
> Cheers,
>
> David
^ permalink raw reply
* Re: [PATCH v3] mm: page_reporting: allow driver to set batch capacity
From: Sasha Levin @ 2026-07-06 13:01 UTC (permalink / raw)
To: Andrew Morton
Cc: Michael S. Tsirkin, linux-kernel, David Hildenbrand (Arm),
Gregory Price, Zi Yan, Pankaj Gupta, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Brendan Jackman, Johannes Weiner, Alexander Duyck, virtualization,
linux-mm
In-Reply-To: <20260705110649.bd30f742c78801a76137c53b@linux-foundation.org>
On Sun, Jul 05, 2026 at 11:06:49AM -0700, Andrew Morton wrote:
>On Sun, 5 Jul 2026 05:06:27 -0400 "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
>> > -stable maintainers have been asked not to do that - only backport
>> > patches which have an explicit cc:stable.
>>
>> Out of curiousity, is this specific to -mm?
>
>Not sure. I have vague memories of being told "we added MM to the
>list", but perhaps I made that up.
>
>Sasha, it MM the only subsystem which requires explicit cc:stable
>for patches to be backported?
There are a few more. We maintain the list here:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/ignore_list
--
Thanks,
Sasha
^ permalink raw reply
* [PATCH v2] vdpa/mlx5: Fix buffer length in create_direct_keys()
From: Christian Borntraeger @ 2026-07-06 13:20 UTC (permalink / raw)
To: Dragos Tatulea
Cc: Michael S . Tsirkin, Jason Wang, virtualization, linux-kernel,
Christian Borntraeger
We have seen in our CI the following KASAN message:
BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core]
Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764
[...]
[<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core]
[<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core]
[<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa]
[<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa]
[...]
The buggy address is located 4128 bytes inside of
allocated 4384-byte region [0000000176794000, 0000000176795120)
So in essence we read 16 bytes beyond 4384-byte allocation.
create_direct_keys calculates the pointer and length for in and out
buffers.
The size calculation for in includes the entire structure
size (out + in + mtt[]) but the pointer passed to cmd_exec points only
to the 'in' field, skipping the 'out' field.
This causes mlx5_copy_to_msg() to read beyond the allocated buffer
by sizeof(out) bytes when copying command data.
Calculates the input size as sizeof(in) + size of the flex array to
match the pointer and allocation size.
Fixes: 0071b138d44a ("vdpa/mlx5: Create direct MKEYs in parallel")
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
---
RFC->v2: use flex_array_size
drivers/vdpa/mlx5/core/mr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
index 6d02ccf9eb91..a3183a0c69c9 100644
--- a/drivers/vdpa/mlx5/core/mr.c
+++ b/drivers/vdpa/mlx5/core/mr.c
@@ -233,7 +233,8 @@ static int create_direct_keys(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_mr *
cmds[i].out = cmd_mem->out;
cmds[i].outlen = sizeof(cmd_mem->out);
cmds[i].in = cmd_mem->in;
- cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount);
+ cmds[i].inlen = sizeof(cmd_mem->in) +
+ flex_array_size(cmd_mem, mtt, mttcount);
fill_create_direct_mr(mvdev, dmr, cmd_mem);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2] virtio_balloon: prime stats vq after virtio_device_ready()
From: David Hildenbrand (Arm) @ 2026-07-06 13:42 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Adam Litke, Rusty Russell, virtualization, Andrew Morton,
linux-mm
In-Reply-To: <20260706070936-mutt-send-email-mst@kernel.org>
On 7/6/26 14:59, Michael S. Tsirkin wrote:
> On Mon, Jul 06, 2026 at 10:57:33AM +0200, David Hildenbrand (Arm) wrote:
>> On 7/6/26 10:43, Michael S. Tsirkin wrote:
>>>
>>> Sorry I do not get the question. Virtio API expects
>>> callers to serialize calls for each VQ. So this just prevents the work
>>> from running and accessing the VQ while probe calls add_buf/kick.
>>> I'll add a comment explaining that.
>>> But it has nothing to do with the spec.
>>
>> The device is clearly not properly initialized yet.
>>
>> Yet, we expect that we get a stats_request() callback that would try to
>> queue_work(). And IIUC, the stats_request() will be directly issued by the device.
>
> With an in-spec device, it can happen right after virtio_device_ready.
> We could defer it a bit, but I don't see what this gets us, and
> this also protects against any out of spec ones.
Agreed.
>
>
>> In QEMU, that would mean that balloon_stats_poll_cb() runs, which would do a
>>
>> if (s->stats_vq_elem == NULL) {
>> ...
>> return
>> }
>>
>> virtqueue_push(s->svq, s->stats_vq_elem, 0);
>> virtio_notify(vdev, s->svq);
>>
>>
>> That's why I'm confused :)
>
> First the spec says there could be interrupts for no reasons right after
> DRIVER_OK. Second there are situations in which qemu might
> consume a buffer without a kick and then an interrupt
> races with the kick.
Okay, makes sense, thanks.
--
Cheers,
David
^ permalink raw reply
* [PATCH v3] virtio_balloon: prime stats vq after virtio_device_ready()
From: Michael S. Tsirkin @ 2026-07-06 13:56 UTC (permalink / raw)
To: linux-kernel
Cc: David Hildenbrand, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Adam Litke, Rusty Russell, virtualization
The virtio spec requires the driver not to kick the device before
DRIVER_OK is set. init_vqs() primes the stats virtqueue with a buffer
and kicks the device before virtio_device_ready() is called in
virtballoon_probe(), violating this requirement.
Further, if the device responds to the early kick by processing the
buffer before DRIVER_OK, stats_request() fires and queues
update_balloon_stats_work. Should probe then fail and free vb, the work
runs against freed memory.
To fix, move buffer setup to after DRIVER_OK. Be careful to
disable update_balloon_stats_work while this is going on,
to make sure it does not race with the setup.
setup_vqs() warns but does not fail probe or restore if
virtqueue_add_outbuf() fails; the call never actually fails in these
contexts since the queue is freshly initialized and empty.
Testing: tested that stats still work after the change.
Fixes: 9564e138b1f6 ("virtio: Add memory statistics reporting to the balloon driver (V4)")
Reported-by: Sashiko:gemini-3.1-pro-preview
Cc: David Hildenbrand <david@kernel.org>
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
v2->v3: add disable_work comment and BUG_ON -> WARN_ON_ONCE (David Hildenbrand)
v1->v2: check that work enable/disable is balanced;
explain how add buf never fails in probe/restore,
add back a warning if it somehow does
drivers/virtio/virtio_balloon.c | 51 +++++++++++++++++++++------------
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 088b3a0e6ce6..83ae1f3cd460 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -611,25 +611,9 @@ static int init_vqs(struct virtio_balloon *vb)
vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
- struct scatterlist sg;
- unsigned int num_stats;
vb->stats_vq = vqs[VIRTIO_BALLOON_VQ_STATS];
-
- /*
- * Prime this virtqueue with one buffer so the hypervisor can
- * use it to signal us later (it can't be broken yet!).
- */
- num_stats = update_balloon_stats(vb);
-
- sg_init_one(&sg, vb->stats, sizeof(vb->stats[0]) * num_stats);
- err = virtqueue_add_outbuf(vb->stats_vq, &sg, 1, vb,
- GFP_KERNEL);
- if (err) {
- dev_warn(&vb->vdev->dev, "%s: add stat_vq failed\n",
- __func__);
- return err;
- }
- virtqueue_kick(vb->stats_vq);
+ /* Prevent update_balloon_stats_work from accessing the stats vq. */
+ disable_work(&vb->update_balloon_stats_work);
}
if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
@@ -916,6 +900,33 @@ static int virtio_balloon_register_shrinker(struct virtio_balloon *vb)
return 0;
}
+static void setup_vqs(struct virtio_balloon *vb)
+{
+ struct scatterlist sg;
+ unsigned int num_stats;
+ bool ret;
+
+ if (!virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ))
+ return;
+
+ /*
+ * Prime this virtqueue with one buffer so the hypervisor can
+ * use it to signal us later (it can't be broken yet!).
+ */
+ num_stats = update_balloon_stats(vb);
+ sg_init_one(&sg, vb->stats, sizeof(vb->stats[0]) * num_stats);
+ if (virtqueue_add_outbuf(vb->stats_vq, &sg, 1, vb, GFP_KERNEL)) {
+ dev_warn(&vb->vdev->dev, "%s: add stat_vq failed\n", __func__);
+ return;
+ }
+ virtqueue_kick(vb->stats_vq);
+
+ ret = enable_and_queue_work(system_freezable_wq,
+ &vb->update_balloon_stats_work);
+ /* Make sure we balanced enable/disable, or we won't report stats. */
+ WARN_ON_ONCE(!ret);
+}
+
static int virtballoon_probe(struct virtio_device *vdev)
{
struct virtio_balloon *vb;
@@ -1059,6 +1070,8 @@ static int virtballoon_probe(struct virtio_device *vdev)
virtio_device_ready(vdev);
+ setup_vqs(vb);
+
if (towards_target(vb))
virtballoon_changed(vdev);
return 0;
@@ -1148,6 +1161,8 @@ static int virtballoon_restore(struct virtio_device *vdev)
virtio_device_ready(vdev);
+ setup_vqs(vb);
+
if (towards_target(vb))
virtballoon_changed(vdev);
update_balloon_size(vb);
--
MST
^ permalink raw reply related
* Re: [RFC/PATCH] vdpa/mlx5: Fix buffer length in create_direct_keys()
From: Dragos Tatulea @ 2026-07-06 13:59 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Michael S . Tsirkin, Jason Wang, virtualization, linux-kernel
In-Reply-To: <530d7a50-3bd0-496a-bf41-3b99c8fbbad4@linux.ibm.com>
On 06.07.26 14:59, Christian Borntraeger wrote:
>
>
> Am 06.07.26 um 14:24 schrieb Dragos Tatulea:
>>
>>
>> On 06.07.26 12:13, Christian Borntraeger wrote:
>>>
>>>
>>> Am 06.07.26 um 12:01 schrieb Christian Borntraeger:
>>>> We have seen in our CI the following KASAN message:
>>>> BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core]
>>>> Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764
>>>> [...]
>>>> [<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core]
>>>> [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core]
>>>> [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa]
>>>> [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa]
>>>> [...]
>>>> The buggy address is located 4128 bytes inside of
>>>> allocated 4384-byte region [0000000176794000, 0000000176795120)
>>>>
>>>> So in essence we read 16 bytes beyond 4384-byte allocation.
>>>> create_direct_keys calculates the pointer and length for in and out
>>>> buffers.
>>>> The size calculation for in includes the entire structure
>>>> size (out + in + mtt[]) but the pointer passed to cmd_exec points only
>>>> to the 'in' field, skipping the 'out' field.
>>>>
>>>> This causes mlx5_copy_to_msg() to read beyond the allocated buffer
>>>> by sizeof(out) bytes when copying command data.
>>>>
>>>> Calculates the input size as sizeof(in) + mtt_array_size to match the
>>>> pointer and allocation size.
>>>>
>>>> Fixes: 0071b138d44a ("vdpa/mlx5: Create direct MKEYs in parallel")
>>>> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
>>>> ---
>>>> drivers/vdpa/mlx5/core/mr.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
>>>> index 6d02ccf9eb91..03fe7f5ca412 100644
>>>> --- a/drivers/vdpa/mlx5/core/mr.c
>>>> +++ b/drivers/vdpa/mlx5/core/mr.c
>>>> @@ -233,7 +233,7 @@ static int create_direct_keys(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_mr *
>>>> cmds[i].out = cmd_mem->out;
>>>> cmds[i].outlen = sizeof(cmd_mem->out);
>>>> cmds[i].in = cmd_mem->in;
>>>> - cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount);
>>>> + cmds[i].inlen = sizeof(cmd_mem->in) + (mttcount * sizeof(cmd_mem->mtt[0]));
>> Woops... Thanks for the catch. The fix is good.
>>
>>>
>>> Assuming the fix is the correct fix, question is, if I should use the offset of in instead, e.g.
>>>
>>> cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount) - offsetof(cmd_mem, in);
>>>
>>> to handle potential alignment and padding aspects.
>>>
>> Seems harder to read. Why not:
>> sizeof(cmd_mem->in) + flex_array_size(cmd_mem, mtts, mttcount) ?
>
> Can do that. I assume we do not have any implicit holes in the structure due to alignment? In
> other words, sizeof(cmd_mem->in) can never be something like 20 (and then the flex array would
> start at 24 to align 8 byte elements). If thats the case I will respin with your proposal.
Weeelll, I checked on a x86_64 build and there is a hole there of 16 bytes. So your second
formula is indeed the way to go.
Thanks,
Dragos
^ permalink raw reply
* [PATCH v3] vdpa/mlx5: Fix buffer length in create_direct_keys()
From: Christian Borntraeger @ 2026-07-06 14:15 UTC (permalink / raw)
To: Dragos Tatulea
Cc: Michael S . Tsirkin, Jason Wang, virtualization, linux-kernel,
Christian Borntraeger
We have seen in our CI the following KASAN message:
BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core]
Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764
[...]
[<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core]
[<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core]
[<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa]
[<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa]
[...]
The buggy address is located 4128 bytes inside of
allocated 4384-byte region [0000000176794000, 0000000176795120)
So in essence we read 16 bytes beyond 4384-byte allocation.
create_direct_keys calculates the pointer and length for in and out
buffers.
The size calculation for in includes the entire structure
size (out + in + mtt[]) but the pointer passed to cmd_exec points only
to the 'in' field, skipping the 'out' field.
This causes mlx5_copy_to_msg() to read beyond the allocated buffer
by sizeof(out) bytes when copying command data.
Properly calculate the input size to match the pointer and allocation size.
Fixes: 0071b138d44a ("vdpa/mlx5: Create direct MKEYs in parallel")
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
---
v2->v3: use full size - offset to handle padding and alignment
RFC->v2: use flex_array_size
drivers/vdpa/mlx5/core/mr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
index 6d02ccf9eb91..d422f3faeb48 100644
--- a/drivers/vdpa/mlx5/core/mr.c
+++ b/drivers/vdpa/mlx5/core/mr.c
@@ -233,7 +233,8 @@ static int create_direct_keys(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_mr *
cmds[i].out = cmd_mem->out;
cmds[i].outlen = sizeof(cmd_mem->out);
cmds[i].in = cmd_mem->in;
- cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount);
+ cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount) -
+ offsetof(struct mlx5_create_mkey_mem, in);
fill_create_direct_mr(mvdev, dmr, cmd_mem);
--
2.53.0
^ permalink raw reply related
* [PATCH v1] virtio-pci: Drop inclusion of <linux/mod_devicetable.h>
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-06 16:22 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang
Cc: Xuan Zhuo, Eugenio Pérez, virtualization, linux-kernel
Among the different device id structures <linux/virtio_pci_legacy.h>
only uses struct virtio_device_id. Include <linux/device-id/virtio.h>
instead of <linux/mod_devicetable.h> to provide that which is more
lightweight and doesn't introduce that many dependencies.
The users of <linux/virtio_pci_legacy.h> also don't rely on this header
to provide the full plethora of definitions. (There are only
drivers/vdpa/alibaba/eni_vdpa.c and drivers/virtio/virtio_pci_common.c
using pci_device_id and these include <linux/pci.h> which is enough to
get it.)
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,
note that <linux/device-id/virtio.h> only exists since v7.2-rc2, so make
sure your base is new enough when applying this patch.
Best regards
Uwe
include/linux/virtio_pci_legacy.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/virtio_pci_legacy.h b/include/linux/virtio_pci_legacy.h
index a8dc757d0367..96a9523e985d 100644
--- a/include/linux/virtio_pci_legacy.h
+++ b/include/linux/virtio_pci_legacy.h
@@ -2,7 +2,7 @@
#ifndef _LINUX_VIRTIO_PCI_LEGACY_H
#define _LINUX_VIRTIO_PCI_LEGACY_H
-#include "linux/mod_devicetable.h"
+#include <linux/device-id/virtio.h>
#include <linux/pci.h>
#include <linux/virtio_pci.h>
base-commit: 8cdeaa50eae8dad34885515f62559ee83e7e8dda
--
2.55.0.11.g153666a7d9bb
^ permalink raw reply related
* Re: [PATCH v5 01/51] x86/apic: Provide helpers to set local APIC timer period in hz and khz
From: Sean Christopherson @ 2026-07-06 18:00 UTC (permalink / raw)
To: Michael Kelley
Cc: Jonathan Corbet, Paolo Bonzini, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86@kernel.org, Kiryl Shutsemau,
Rick Edgecombe, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Ajay Kaher, Alexey Makhalov, Jan Kiszka,
Andy Lutomirski, Peter Zijlstra, Juergen Gross, Daniel Lezcano,
John Stultz, Shuah Khan, H. Peter Anvin, Vitaly Kuznetsov,
Broadcom internal kernel review list, Boris Ostrovsky,
Stephen Boyd, linux-doc@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev,
linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
xen-devel@lists.xenproject.org, Tom Lendacky, Nikunj A Dadhania,
David Woodhouse, David Woodhouse, Thomas Gleixner
In-Reply-To: <SN6PR02MB41578D3C34AB283B892C27A4D4F52@SN6PR02MB4157.namprd02.prod.outlook.com>
On Thu, Jul 02, 2026, Michael Kelley wrote:
> > @@ -796,6 +796,16 @@ bool __init apic_needs_pit(void)
> > return lapic_timer_period == 0;
> > }
> >
> > +void apic_set_timer_period_khz(u64 period_khz, const char *source)
> > +{
> > + lapic_timer_period = mul_u64_u32_div(period_khz, 1000, HZ);
> > +}
> > +
> > +void apic_set_timer_period_hz(u64 period_hz, const char *source)
> > +{
> > + lapic_timer_period = div_u64(period_hz, HZ);
> > +}
>
> A string "source" argument is passed in, but not used. Is there an
> envisioned future use? Also, this function doesn't output a pr_info()
> message like the existing Hyper-V and VMware code does.
It was a complete goof on my part (Sashiko also pointed out the oddity[*]). I
fully intended to log a message and provide equivalent Hyper-V/VMware behavior,
and totally spaced it.
[*] https://lore.kernel.org/all/20260701194621.4BD691F000E9@smtp.kernel.org
> I don't know that the message is all that useful, though I do remember one
> case where I was debugging some clock/timer issue when I looked at it.
^ permalink raw reply
* Re: [PATCH 02/13] mm/vma: update do_mmap() to use vma_flags_t
From: Zi Yan @ 2026-07-07 2:10 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton
Cc: Thomas Bogendoerfer, Madhavan Srinivasan, Michael Ellerman,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Lucas Stach, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Rob Clark,
Dmitry Baryshkov, Lyude Paul, Danilo Krummrich, Tomi Valkeinen,
Sandy Huang, Heiko Stübner, Andy Yan, Thierry Reding,
Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann, Dmitry Osipenko,
Zack Rusin, Matthew Brost, Thomas Hellstrom,
Oleksandr Andrushchenko, Helge Deller, Benjamin LaHaise,
Alexander Viro, Christian Brauner, Muchun Song, Oscar Salvador,
David Hildenbrand, Baolin Wang, Liam R . Howlett, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Hugh Dickins,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Kees Cook, Jaroslav Kysela,
Takashi Iwai, linux-mips, linux-kernel, linuxppc-dev, dri-devel,
etnaviv, linux-arm-kernel, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-aio,
linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <e0ac58ad2b88ff7e2f0024e3286b2e786f79ca32.1782760670.git.ljs@kernel.org>
On Mon Jun 29, 2026 at 3:25 PM EDT, Lorenzo Stoakes wrote:
> The core do_mmap() function accepts a vm_flags_t parameter which it then
> manipulates before passing to mmap_region() to do the heavy lifting of the
> memory mapping.
>
> Update do_mmap() to instead accept a vma_flags_t parameter, and adjust all
> the logic within do_mmap() to manipulate this instead.
>
> This is as part of the ongoing effort to convert VMA flags from a system
> word size to a bitmap type which allows us to unrestrict the number of VMA
> flags, as well as gain control over how VMA flag manipulation occurs.
>
> We do not cascade these changes to all functions which accept vm_flags_t,
> but rather use vma_flags_to_legacy() where necessary, specifically
> deferring converting calc_vm_prot_bits(), calc_vm_flag_bits() and
> __get_unmapped_area() to vma_flags_t.
>
> Also utilise the new vma_flags_can_grow() predicate which correctly handles
> the case of architectures without upward growing stacks.
>
> As part of this change, introduce VMA_SHADOW_STACK so we can correctly
> handle the case of the shadow stack not being defined.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> arch/mips/kernel/vdso.c | 4 +--
> fs/aio.c | 2 +-
> include/linux/memfd.h | 6 ++--
> include/linux/mm.h | 6 ++--
> ipc/shm.c | 3 +-
> mm/memfd.c | 15 ++++-----
> mm/mmap.c | 67 ++++++++++++++++++++++++-----------------
> mm/nommu.c | 3 +-
> mm/util.c | 10 +++---
> mm/vma.c | 7 ++---
> mm/vma.h | 2 +-
> 11 files changed, 69 insertions(+), 56 deletions(-)
>
<snip>
>
> -static int check_write_seal(vm_flags_t *vm_flags_ptr)
> +static int check_write_seal(vma_flags_t *vma_flags_ptr)
> {
> - vm_flags_t vm_flags = *vm_flags_ptr;
> - vm_flags_t mask = vm_flags & (VM_SHARED | VM_WRITE);
> -
> /* If a private mapping then writability is irrelevant. */
> - if (!(mask & VM_SHARED))
> + if (!vma_flags_test(vma_flags_ptr, VMA_SHARED_BIT))
> return 0;
>
> /*
> * New PROT_WRITE and MAP_SHARED mmaps are not allowed when
> * write seals are active.
> */
> - if (mask & VM_WRITE)
> + if (vma_flags_test(vma_flags_ptr, VMA_WRITE_BIT))
> return -EPERM;
>
> /*
> * This is a read-only mapping, disallow mprotect() from making a
> * write-sealed mapping writable in future.
> */
> - *vm_flags_ptr &= ~VM_MAYWRITE;
> + vma_flags_clear(vma_flags_ptr, VMA_MAYWRITE_BIT);
>
> return 0;
> }
This function alone changed its original behavior, since vm_flags is a
snapshot of *vm_flags_ptr, but after the change this snapshot is gone.
But its only caller memfd_check_seals_mmap() gets vm_flags_ptr from the
input parameter of do_mmap(), so the overall behavior does not change.
<snip>
> + case MAP_DROPPABLE: {
> + vma_flags_t droppable = VMA_DROPPABLE;
> +
> + if (vma_flags_empty(&droppable))
> return -EOPNOTSUPP;
> + vma_flags_set_mask(&vma_flags, droppable);
> +
> /*
> * A locked or stack area makes no sense to be droppable.
> *
> @@ -515,23 +527,24 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
> */
> if (flags & (MAP_LOCKED | MAP_HUGETLB))
> return -EINVAL;
> - if (vm_flags & (VM_GROWSDOWN | VM_GROWSUP))
> + if (vma_flags_can_grow(&vma_flags))
> return -EINVAL;
>
> - vm_flags |= VM_DROPPABLE;
> -
Lance pointed out the reordering of setting VMA_DROPPABLE and checking
of can_grow, but these flags are not overlapped and there is no parallel
writer to vma_flags. So it is still no functional change, just not
mechanical changes. :)
Otherwise, LGTM.
Reviewed-by: Zi Yan <ziy@nvidia.com>
--
Best Regards,
Yan, Zi
^ permalink raw reply
* Re: [PATCH 03/13] mm: convert __get_unmapped_area() to use vma_flags_t
From: Zi Yan @ 2026-07-07 2:28 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton
Cc: Thomas Bogendoerfer, Madhavan Srinivasan, Michael Ellerman,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Lucas Stach, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Rob Clark,
Dmitry Baryshkov, Lyude Paul, Danilo Krummrich, Tomi Valkeinen,
Sandy Huang, Heiko Stübner, Andy Yan, Thierry Reding,
Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann, Dmitry Osipenko,
Zack Rusin, Matthew Brost, Thomas Hellstrom,
Oleksandr Andrushchenko, Helge Deller, Benjamin LaHaise,
Alexander Viro, Christian Brauner, Muchun Song, Oscar Salvador,
David Hildenbrand, Baolin Wang, Liam R . Howlett, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Hugh Dickins,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Kees Cook, Jaroslav Kysela,
Takashi Iwai, linux-mips, linux-kernel, linuxppc-dev, dri-devel,
etnaviv, linux-arm-kernel, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-aio,
linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <b1ad7c4443f5cba622e4c48c5a9ef15427001a93.1782760670.git.ljs@kernel.org>
On Mon Jun 29, 2026 at 3:25 PM EDT, 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.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> fs/hugetlbfs/inode.c | 3 ++-
> include/linux/huge_mm.h | 10 +++++-----
> include/linux/mm.h | 6 ++++--
> include/linux/sched/mm.h | 12 ++++++------
> mm/huge_memory.c | 21 ++++++++++++---------
> mm/mmap.c | 27 ++++++++++++++-------------
> 6 files changed, 43 insertions(+), 36 deletions(-)
>
<snip>
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> index 95d0040df584..b301ec90740a 100644
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -193,12 +193,12 @@ unsigned long mm_get_unmapped_area(struct file *filp, unsigned long addr,
> unsigned long len, unsigned long pgoff,
> unsigned long flags);
>
> -unsigned long mm_get_unmapped_area_vmflags(struct file *filp,
> - unsigned long addr,
> - unsigned long len,
> - unsigned long pgoff,
> - unsigned long flags,
> - vm_flags_t vm_flags);
> +unsigned long mm_get_unmapped_area_vmaflags(struct file *filp,
> + unsigned long addr,
> + unsigned long len,
> + unsigned long pgoff,
> + unsigned long flags,
> + vma_flags_t vma_flags);
Want to use two-tab indentation while at it?
<snip>
> @@ -812,19 +811,20 @@ arch_get_unmapped_area_topdown(struct file *filp, unsigned long addr,
> }
> #endif
>
> -unsigned long mm_get_unmapped_area_vmflags(struct file *filp, unsigned long addr,
> - unsigned long len, unsigned long pgoff,
> - unsigned long flags, vm_flags_t vm_flags)
> +unsigned long mm_get_unmapped_area_vmaflags(struct file *filp, unsigned long addr,
> + unsigned long len, unsigned long pgoff,
> + unsigned long flags, vma_flags_t vma_flags)
Ditto.
LGTM.
Reviewed-by: Zi Yan <ziy@nvidia.com>
--
Best Regards,
Yan, Zi
^ permalink raw reply
* Re: [PATCH 04/13] mm: update generic_get_unmapped_area[_topdown]() to use vma_flags_t
From: Zi Yan @ 2026-07-07 2:29 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton
Cc: Thomas Bogendoerfer, Madhavan Srinivasan, Michael Ellerman,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Lucas Stach, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Rob Clark,
Dmitry Baryshkov, Lyude Paul, Danilo Krummrich, Tomi Valkeinen,
Sandy Huang, Heiko Stübner, Andy Yan, Thierry Reding,
Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann, Dmitry Osipenko,
Zack Rusin, Matthew Brost, Thomas Hellstrom,
Oleksandr Andrushchenko, Helge Deller, Benjamin LaHaise,
Alexander Viro, Christian Brauner, Muchun Song, Oscar Salvador,
David Hildenbrand, Baolin Wang, Liam R . Howlett, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Hugh Dickins,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Kees Cook, Jaroslav Kysela,
Takashi Iwai, linux-mips, linux-kernel, linuxppc-dev, dri-devel,
etnaviv, linux-arm-kernel, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-aio,
linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <cef55b19f86c110952f13829aefa4859db3a70ed.1782760670.git.ljs@kernel.org>
On Mon Jun 29, 2026 at 3:25 PM EDT, 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.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> arch/powerpc/mm/book3s64/slice.c | 6 ++++--
> include/linux/sched/mm.h | 4 ++--
> mm/mmap.c | 16 ++++++++--------
> 3 files changed, 14 insertions(+), 12 deletions(-)
>
LGTM.
Reviewed-by: Zi Yan <ziy@nvidia.com>
--
Best Regards,
Yan, Zi
^ permalink raw reply
* Re: [PATCH v3] vdpa/mlx5: Fix buffer length in create_direct_keys()
From: Christian Borntraeger @ 2026-07-07 7:17 UTC (permalink / raw)
To: Dragos Tatulea
Cc: Michael S . Tsirkin, Jason Wang, virtualization, linux-kernel
In-Reply-To: <20260706141537.3510294-1-borntraeger@linux.ibm.com>
Am 06.07.26 um 16:15 schrieb Christian Borntraeger:
> We have seen in our CI the following KASAN message:
> BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core]
> Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764
> [...]
> [<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core]
> [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core]
> [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa]
> [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa]
> [...]
> The buggy address is located 4128 bytes inside of
> allocated 4384-byte region [0000000176794000, 0000000176795120)
>
> So in essence we read 16 bytes beyond 4384-byte allocation.
> create_direct_keys calculates the pointer and length for in and out
> buffers.
> The size calculation for in includes the entire structure
> size (out + in + mtt[]) but the pointer passed to cmd_exec points only
> to the 'in' field, skipping the 'out' field.
>
> This causes mlx5_copy_to_msg() to read beyond the allocated buffer
> by sizeof(out) bytes when copying command data.
>
> Properly calculate the input size to match the pointer and allocation size.
>
> Fixes: 0071b138d44a ("vdpa/mlx5: Create direct MKEYs in parallel")
> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Dragos,
With this fix our nighly CI did not result in a kasan message. As I only have
limited test coverage a full regression on your side might still be the right
thing to do.
^ permalink raw reply
* Re: [PATCH net 1/2] vsock/virtio: collapse receive queue under memory pressure
From: Stefano Garzarella @ 2026-07-07 9:27 UTC (permalink / raw)
To: Bobby Eshleman
Cc: netdev, Jason Wang, Jakub Kicinski, Paolo Abeni,
Michael S. Tsirkin, kvm, virtualization, Xuan Zhuo, Eric Dumazet,
Simon Horman, linux-kernel, Stefan Hajnoczi, David S. Miller,
Eugenio Pérez, stable, Brien Oberstein
In-Reply-To: <akbFcMHenseQW7mJ@devvm29614.prn0.facebook.com>
On Thu, Jul 02, 2026 at 01:09:20PM -0700, Bobby Eshleman wrote:
>On Thu, Jul 02, 2026 at 10:56:04AM +0200, Stefano Garzarella wrote:
>> On Wed, Jul 01, 2026 at 09:34:35AM -0700, Bobby Eshleman wrote:
>> > On Fri, Jun 26, 2026 at 03:48:22PM +0200, Stefano Garzarella wrote:
>>
>> [...]
>>
>> > > +out:
>> > > + if (new_skb)
>> > > + __skb_queue_tail(&new_queue, new_skb);
>> > > +
>> > > + skb_queue_splice(&new_queue, &vvs->rx_queue);
>> >
>> > I think the new skbs will also need skb_set_owner_sk_safe(skb, sk)
>> > when adding to rx_queue?
>>
>> IIRC we added it in the rx path, mainily for loopback to pass the ownership
>> from the tx socket to the rx socket, but here we are already in the rx path,
>> so the skb will never leave this socket.
>>
>
>Ah that's right, I stand corrected. There is no sender to leak in this
>case.
>
>> Maybe it's necessary for the eBPF path?
>
>Looking through sockmap, I don't think it depends on skb->sk being
>non-null either (it reassigns owner to the redirect socket anyway using
>skb_set_owner_r()).
>
>Sorry for the false alarm. LGTM.
Thanks for checking!
>
>Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
>
I'm going to add a threashold as Paolo suggested. Do you prefer to look
at v2 or should I carry your R-b ?
Thanks,
Stefano
^ permalink raw reply
* Re: [PATCH 02/13] mm/vma: update do_mmap() to use vma_flags_t
From: Lorenzo Stoakes @ 2026-07-07 10:15 UTC (permalink / raw)
To: Zi Yan
Cc: Andrew Morton, Thomas Bogendoerfer, Madhavan Srinivasan,
Michael Ellerman, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Inki Dae, Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski,
Peter Griffin, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Rob Clark, Dmitry Baryshkov, Lyude Paul,
Danilo Krummrich, Tomi Valkeinen, Sandy Huang, Heiko Stübner,
Andy Yan, Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Gerd Hoffmann, Dmitry Osipenko, Zack Rusin, Matthew Brost,
Thomas Hellstrom, Oleksandr Andrushchenko, Helge Deller,
Benjamin LaHaise, Alexander Viro, Christian Brauner, Muchun Song,
Oscar Salvador, David Hildenbrand, Baolin Wang, Liam R . Howlett,
Nico Pache, Ryan Roberts, Dev Jain, Barry Song, Lance Yang,
Hugh Dickins, Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan,
Michal Hocko, Jann Horn, Pedro Falcato, Kees Cook,
Jaroslav Kysela, Takashi Iwai, linux-mips, linux-kernel,
linuxppc-dev, dri-devel, etnaviv, linux-arm-kernel,
linux-samsung-soc, intel-gfx, linux-arm-msm, freedreno, nouveau,
linux-rockchip, linux-tegra, virtualization, intel-xe, xen-devel,
linux-fbdev, linux-aio, linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <DJRZ2QCEIVA6.1AZF5S891NKS4@nvidia.com>
On Mon, Jul 06, 2026 at 10:10:32PM -0400, Zi Yan wrote:
> On Mon Jun 29, 2026 at 3:25 PM EDT, Lorenzo Stoakes wrote:
> > The core do_mmap() function accepts a vm_flags_t parameter which it then
> > manipulates before passing to mmap_region() to do the heavy lifting of the
> > memory mapping.
> >
> > Update do_mmap() to instead accept a vma_flags_t parameter, and adjust all
> > the logic within do_mmap() to manipulate this instead.
> >
> > This is as part of the ongoing effort to convert VMA flags from a system
> > word size to a bitmap type which allows us to unrestrict the number of VMA
> > flags, as well as gain control over how VMA flag manipulation occurs.
> >
> > We do not cascade these changes to all functions which accept vm_flags_t,
> > but rather use vma_flags_to_legacy() where necessary, specifically
> > deferring converting calc_vm_prot_bits(), calc_vm_flag_bits() and
> > __get_unmapped_area() to vma_flags_t.
> >
> > Also utilise the new vma_flags_can_grow() predicate which correctly handles
> > the case of architectures without upward growing stacks.
> >
> > As part of this change, introduce VMA_SHADOW_STACK so we can correctly
> > handle the case of the shadow stack not being defined.
> >
> > No functional change intended.
> >
> > Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> > ---
> > arch/mips/kernel/vdso.c | 4 +--
> > fs/aio.c | 2 +-
> > include/linux/memfd.h | 6 ++--
> > include/linux/mm.h | 6 ++--
> > ipc/shm.c | 3 +-
> > mm/memfd.c | 15 ++++-----
> > mm/mmap.c | 67 ++++++++++++++++++++++++-----------------
> > mm/nommu.c | 3 +-
> > mm/util.c | 10 +++---
> > mm/vma.c | 7 ++---
> > mm/vma.h | 2 +-
> > 11 files changed, 69 insertions(+), 56 deletions(-)
> >
>
> <snip>
>
> >
> > -static int check_write_seal(vm_flags_t *vm_flags_ptr)
> > +static int check_write_seal(vma_flags_t *vma_flags_ptr)
> > {
> > - vm_flags_t vm_flags = *vm_flags_ptr;
> > - vm_flags_t mask = vm_flags & (VM_SHARED | VM_WRITE);
> > -
> > /* If a private mapping then writability is irrelevant. */
> > - if (!(mask & VM_SHARED))
> > + if (!vma_flags_test(vma_flags_ptr, VMA_SHARED_BIT))
> > return 0;
> >
> > /*
> > * New PROT_WRITE and MAP_SHARED mmaps are not allowed when
> > * write seals are active.
> > */
> > - if (mask & VM_WRITE)
> > + if (vma_flags_test(vma_flags_ptr, VMA_WRITE_BIT))
> > return -EPERM;
> >
> > /*
> > * This is a read-only mapping, disallow mprotect() from making a
> > * write-sealed mapping writable in future.
> > */
> > - *vm_flags_ptr &= ~VM_MAYWRITE;
> > + vma_flags_clear(vma_flags_ptr, VMA_MAYWRITE_BIT);
> >
> > return 0;
> > }
>
> This function alone changed its original behavior, since vm_flags is a
> snapshot of *vm_flags_ptr, but after the change this snapshot is gone.
> But its only caller memfd_check_seals_mmap() gets vm_flags_ptr from the
> input parameter of do_mmap(), so the overall behavior does not change.
Right yeah, the snapshot was always just a convenience thing :)
>
> <snip>
>
> > + case MAP_DROPPABLE: {
> > + vma_flags_t droppable = VMA_DROPPABLE;
> > +
> > + if (vma_flags_empty(&droppable))
> > return -EOPNOTSUPP;
> > + vma_flags_set_mask(&vma_flags, droppable);
> > +
> > /*
> > * A locked or stack area makes no sense to be droppable.
> > *
> > @@ -515,23 +527,24 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
> > */
> > if (flags & (MAP_LOCKED | MAP_HUGETLB))
> > return -EINVAL;
> > - if (vm_flags & (VM_GROWSDOWN | VM_GROWSUP))
> > + if (vma_flags_can_grow(&vma_flags))
> > return -EINVAL;
> >
> > - vm_flags |= VM_DROPPABLE;
> > -
>
> Lance pointed out the reordering of setting VMA_DROPPABLE and checking
> of can_grow, but these flags are not overlapped and there is no parallel
> writer to vma_flags. So it is still no functional change, just not
> mechanical changes. :)
Right yes exactly :)
>
> Otherwise, LGTM.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
Thanks!
>
> --
> Best Regards,
> Yan, Zi
>
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH 03/13] mm: convert __get_unmapped_area() to use vma_flags_t
From: Lorenzo Stoakes @ 2026-07-07 10:16 UTC (permalink / raw)
To: Zi Yan
Cc: Andrew Morton, Thomas Bogendoerfer, Madhavan Srinivasan,
Michael Ellerman, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Inki Dae, Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski,
Peter Griffin, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Rob Clark, Dmitry Baryshkov, Lyude Paul,
Danilo Krummrich, Tomi Valkeinen, Sandy Huang, Heiko Stübner,
Andy Yan, Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Gerd Hoffmann, Dmitry Osipenko, Zack Rusin, Matthew Brost,
Thomas Hellstrom, Oleksandr Andrushchenko, Helge Deller,
Benjamin LaHaise, Alexander Viro, Christian Brauner, Muchun Song,
Oscar Salvador, David Hildenbrand, Baolin Wang, Liam R . Howlett,
Nico Pache, Ryan Roberts, Dev Jain, Barry Song, Lance Yang,
Hugh Dickins, Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan,
Michal Hocko, Jann Horn, Pedro Falcato, Kees Cook,
Jaroslav Kysela, Takashi Iwai, linux-mips, linux-kernel,
linuxppc-dev, dri-devel, etnaviv, linux-arm-kernel,
linux-samsung-soc, intel-gfx, linux-arm-msm, freedreno, nouveau,
linux-rockchip, linux-tegra, virtualization, intel-xe, xen-devel,
linux-fbdev, linux-aio, linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <DJRZGEZU5ESV.3IP5LEAUQJCBK@nvidia.com>
On Mon, Jul 06, 2026 at 10:28:24PM -0400, Zi Yan wrote:
> On Mon Jun 29, 2026 at 3:25 PM EDT, 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.
> >
> > Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> > ---
> > fs/hugetlbfs/inode.c | 3 ++-
> > include/linux/huge_mm.h | 10 +++++-----
> > include/linux/mm.h | 6 ++++--
> > include/linux/sched/mm.h | 12 ++++++------
> > mm/huge_memory.c | 21 ++++++++++++---------
> > mm/mmap.c | 27 ++++++++++++++-------------
> > 6 files changed, 43 insertions(+), 36 deletions(-)
> >
> <snip>
>
> > diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> > index 95d0040df584..b301ec90740a 100644
> > --- a/include/linux/sched/mm.h
> > +++ b/include/linux/sched/mm.h
> > @@ -193,12 +193,12 @@ unsigned long mm_get_unmapped_area(struct file *filp, unsigned long addr,
> > unsigned long len, unsigned long pgoff,
> > unsigned long flags);
> >
> > -unsigned long mm_get_unmapped_area_vmflags(struct file *filp,
> > - unsigned long addr,
> > - unsigned long len,
> > - unsigned long pgoff,
> > - unsigned long flags,
> > - vm_flags_t vm_flags);
> > +unsigned long mm_get_unmapped_area_vmaflags(struct file *filp,
> > + unsigned long addr,
> > + unsigned long len,
> > + unsigned long pgoff,
> > + unsigned long flags,
> > + vma_flags_t vma_flags);
>
> Want to use two-tab indentation while at it?
Yeah sure will fix on respin!
>
> <snip>
>
> > @@ -812,19 +811,20 @@ arch_get_unmapped_area_topdown(struct file *filp, unsigned long addr,
> > }
> > #endif
> >
> > -unsigned long mm_get_unmapped_area_vmflags(struct file *filp, unsigned long addr,
> > - unsigned long len, unsigned long pgoff,
> > - unsigned long flags, vm_flags_t vm_flags)
> > +unsigned long mm_get_unmapped_area_vmaflags(struct file *filp, unsigned long addr,
> > + unsigned long len, unsigned long pgoff,
> > + unsigned long flags, vma_flags_t vma_flags)
>
> Ditto.
Ack will fix!
>
> LGTM.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
Thanks!
>
>
> --
> Best Regards,
> Yan, Zi
>
Cheers, Lorenzo
^ permalink raw reply
* [PATCH v4 0/4] Add queue ready message to VDUSE
From: Eugenio Pérez @ 2026-07-07 12:24 UTC (permalink / raw)
To: Michael S . Tsirkin
Cc: Eugenio Pérez, Laurent Vivier, Yongji Xie, linux-kernel,
Stefano Garzarella, Jason Wang, Xuan Zhuo, virtualization,
Maxime Coquelin
This series introduces a new VDUSE message for VDUSE userland instance
to detect when a VirtQueue (VQ) is enabled, replacing the polling.
VirtIO net devices' dataplane is started after the control virtqueue so
QEMU can apply the configuration in the destination of a Live Migration.
Without this feature, the VDUSE instance must poll the VQs to check when
(and if) a VQ has been enabled.
This series also implements VDUSE feature flags allowing the VDUSE
devices to opt-in to the VQ ready message. Devices that opt-in to this
feature will receive explicit notifications when a VQ is ready. Devices
that do not set this flag remain unaffected, ensuring backward
compatibility without indefinitely incrementing API versions.
The VDUSE features is a 64 bit bitmap for simplicity, the same way as
vhost and vhost-net started. It can be extended as a flexible array of
bits when we reach so many features, but it seems unlikely at this
point.
Error cases tested:
* Call VDUSE_GET_FEATURES without get the API VERSION (so API == 0) and
with API VERSION set to 1 with VDUSE_SET_API_VERSION (-EINVAL returned
from VDUSE_GET_FEATURES ioctl).
* Try to set invalid features.
* Test regular initialization of single queue devices with and without
VDUSE_F_QUEUE_READY set.
* Test expected behavior when VDUSE userland instance returns
VDUSE_REQ_RESULT_FAILED from VDUSE_SET_VQ_READY message.
* Repeat all the tests with multiqueue devices, by reverting
56e71885b0349 ("vduse: Temporarily fail if control queue feature requested").
v4:
* Create its own spinlock for vq->ready instead of relying on kick and
call spinlocks.
* Add VDUSE_SET_FEATURES ioctl and the corresponding validation paths instead
of using device config.
v3:
* Remove API_VERSION bump to 2
* Add comment about struct vduse_dev_config:vduse_features is only valid
if VDUSE_GET_FEATURES success.
v2:
* Fix comment of vduse_dev_request.vq_ready
* Set vq_ready before sending the message to the VDUSE userland
instance, avoiding the need for SMP sync after receiving the message.
* Return -EINVAL if control ioctl called with version < 2, so userland
visible reply is kept (Jason).
Eugenio Pérez (4):
vduse: store control device pointer
vduse: add VDUSE_GET_FEATURES ioctl
vduse: add VDUSE_SET_FEATURES ioctl
vduse: add F_QUEUE_READY feature
drivers/vdpa/vdpa_user/vduse_dev.c | 111 +++++++++++++++++++++++------
include/uapi/linux/vduse.h | 24 +++++++
2 files changed, 115 insertions(+), 20 deletions(-)
--
2.55.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