* [PATCH v5 51/51] x86/kvm: Get local APIC bus frequency from PV CPUID Timing Info
From: Sean Christopherson @ 2026-07-01 19:32 UTC (permalink / raw)
To: Jonathan Corbet, Paolo Bonzini, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, Kiryl Shutsemau,
Rick Edgecombe, Sean Christopherson, 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
Cc: Shuah Khan, H. Peter Anvin, Vitaly Kuznetsov,
Broadcom internal kernel review list, Boris Ostrovsky,
Stephen Boyd, linux-doc, kvm, linux-kernel, linux-coco,
linux-hyperv, virtualization, xen-devel, Tom Lendacky,
Nikunj A Dadhania, David Woodhouse, David Woodhouse,
Michael Kelley, Thomas Gleixner
In-Reply-To: <20260701193212.749551-1-seanjc@google.com>
When running as a KVM guest with PV timing info provided by the host,
stuff the APIC timer period/frequency with the local APIC bus frequency
reported in CPUID.0x40000010.EBX instead of trying to calibrate/guess the
frequency.
See Documentation/virt/kvm/x86/cpuid.rst for details.
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/kernel/kvm.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index f9a6346077b0..beea0b6aa78e 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -990,7 +990,7 @@ static void __init kvm_init_platform(void)
.mask_lo = (u32)(~(SZ_4G - tolud - 1)) | MTRR_PHYSMASK_V,
.mask_hi = (BIT_ULL(boot_cpu_data.x86_phys_bits) - 1) >> 32,
};
- u32 timing_info_leaf;
+ u32 timing_info_leaf, apic_khz;
bool tsc_is_reliable;
if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
@@ -1052,6 +1052,11 @@ static void __init kvm_init_platform(void)
x86_init.hyper.get_tsc_khz = kvm_get_tsc_khz;
x86_init.hyper.get_cpu_khz = kvm_get_tsc_khz;
}
+
+ /* The leaf also includes the local APIC bus/timer frequency.*/
+ apic_khz = cpuid_ebx(timing_info_leaf);
+ if (apic_khz)
+ apic_set_timer_period_khz(apic_khz, "KVM hypervisor");
}
/*
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* Re: [PATCH] drm/virtio: defer hotplug event from dequeue worker to avoid deadlock
From: Hillf Danton @ 2026-07-01 23:43 UTC (permalink / raw)
To: Ryosuke Yasuoka
Cc: Dmitry Osipenko, Dmitry Baryshkov, Javier Martinez Canillas,
dri-devel, virtualization, linux-kernel
In-Reply-To: <18be2016e26ade27.a6e9e2496bc1f978.9bc3a62421115997@ryasuoka-thinkpadx1carbongen9.tokyo.csb>
On Wed, 1 Jul 2026 09:23:05 +0000 Ryosuke Yasuoka wrote:
>On 30/06/2026 16:46, Dmitry Osipenko wrote:
>> Could you please move drm_kms_helper_hotplug_event() to virtio_gpu_init(),
>> placing it after wait_event_timeout(display_info_pending)? This will avoid
>> additional work_struct that otherwise needs to be cancelled in
>> virtio_gpu_init() on the timeout.
>
>IIUC, moving the drm_kms_helper_hotplug_event() and _hpd_irq_event()
>into virtio_gpu_init() after wait_event_timeout() would not prevent the
>issue.
>
>Looking at the syzbot call traces[1][2], the deadlock occurs during
>drm_client_setup(), which runs after virtio_gpu_init() has already
>returned. The display_info_cb that triggers the deadlock is called from
>the dequeue worker while drm_client_register() holds clientlist_mutex.
>
>Thread A:
>virtio_gpu_probe()
> -> virtio_gpu_init() // sends GET_DISPLAY_INFO and waits up to 5s
> -> drm_dev_register()
> -> drm_client_setup() // deadlock happens HERE
> -> drm_client_register() // holds clientlist_mutex
> ...
> -> virtio_gpu_queue_fenced_ctrl_buffer()
> -> wait_event() // waits for free space
>
>Thread B:
>virtio_gpu_dequeue_ctrl_func()
> -> reclaim_vbufs() // make free space
I wonder if the deadlock could be cured by alternatively adding a wakeup
before the responce cb, given that free space is available.
> -> resp_cb()
> -> virtio_gpu_cmd_get_display_info_cb
> -> drm_helper_hpd_irq_event()
> -> drm_kms_helper_hotplug_event()
> -> drm_client_dev_hotplug() // need to lock clientlist_mutex
> -> wake_up() // never reached
>
>IIUC the hotplug notification in display_info_cb is needed because it
>notifies DRM after updating by the callback with fresh data from the host.
>
>This work_struct ensures display_info_cb never blocks on
>clientlist_mutex in the dequeue worker, while preserving the hotplug
>notification with fresh data.
>
>[1] https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224
>[2] https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e
>
>Best regards,
>Ryosuke
^ permalink raw reply
* Re: [PATCH v2 2/2] tools/include: Include stdint.h for SIZE_MAX in overflow.h
From: Yichong Chen @ 2026-07-02 2:20 UTC (permalink / raw)
To: sj
Cc: akpm, chenyichong, eperezma, jasowang, linux-kernel, ljs, mst,
pabeni, rppt, virtualization, xuanzhuo
In-Reply-To: <20260701133503.41823-1-sj@kernel.org>
Hi SJ,
You are right. The include should be inside the header guard, after
#define __LINUX_OVERFLOW_H.
I will fix it in the next version.
Thanks,
Yichong
^ permalink raw reply
* Re: [syzbot] Monthly virt report (Jun 2026)
From: mawupeng @ 2026-07-02 2:55 UTC (permalink / raw)
To: syzbot+listbf7b8eeeb8dda31d6de1, linux-kernel, syzkaller-bugs,
virtualization, mst, jasowang, xuanzhuo, eperezma, stefanha,
sgarzare, davem, edumazet, kuba, pabeni, horms
Cc: mawupeng1, virtualization, kvm, netdev
In-Reply-To: <6a3c3ed6.80e5668d.5d0ef.0001.GAE@google.com>
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.
== Root cause ==
The leaked object is the child socket created by
virtio_transport_recv_listen() via __vsock_create() — exactly the
allocation site kmemleak points at. The reason it never gets freed is
in the accept() error path, not in the allocation itself.
When vsock_accept() dequeues a child but the listener carries an error
(listener->sk_err, e.g. set by a failed connect() issued on the socket
before listen()), it sets vconnected->rejected = true, skips
sock_graft(), drops the dequeue reference and *relies on
vsock_pending_work()* to clean the child up.
The catch: vsock_pending_work() is never scheduled on the transports
involved here. It is only ever scheduled by vmci_transport
(vmci_transport.c:1130); virtio_transport and vsock_loopback never
schedule it. So the rejected child sits with an unreleased initial
reference (the one from sk_alloc()) plus the connected-table
reference, vsock_sk_destruct() is never reached, and the cascade —
child socket, struct cred, virtio transport, SELinux blob — all leak.
The earlier commit 3a5cc90a4d17 ("vsock/virtio: remove socket from
connected/bound list on shutdown") adds an unconditional
vsock_remove_sock() in virtio_transport_recv_connected() when a
SHUTDOWN arrives, which drops the connected-table reference for a
child that later receives a SHUTDOWN; but it does not release the
sk_alloc() reference. So the leak is not really a regression
introduced there — rejected children have never been cleaned up on
transports that don't schedule pending_work. 3a5cc90a4d17 mainly
changes whether kmemleak can see the leak: on v6.6 it can (the
cascade shows up), on mainline the smaller struct sock layout leaves a
residual pointer inside the child that kmemleak counts as a reachable
reference, so mainline kmemleak stays silent even though
create/destruct accounting confirms the child never reaches
vsock_sk_destruct().
== Why the previous attempt didn't land ==
Divya's patch [1] tried to fix it by re-locking the parent listener
inside virtio_transport_recv_listen() and re-checking the shutdown
state under that lock before vsock_enqueue_accept(). That re-locks an
already-held lock — virtio_transport_recv_pkt() holds lock_sock(sk)
across the call into recv_listen() — and syzbot ci immediately flagged
"possible recursive locking" [2]. So it was backed out and the bug
stayed open.
== A direction that tests out ==
Instead of re-locking in the receive path, handle the cleanup directly
in vsock_accept(): on reject, instead of setting vconnected->rejected
and relying on pending_work, explicitly release the child's references
there:
if (err) {
vsock_remove_connected(vconnected); /* connected-table ref */
connected->sk_state = TCP_CLOSE;
sock_put(connected); /* enqueue_accept ref */
} else {
sock_graft(connected, newsock);
}
...
sock_put(connected); /* the existing, common put — sk_alloc ref */
This drops exactly the three references the child holds at dequeue
time (sk_alloc + __vsock_insert_connected + vsock_enqueue_accept),
lets refcount reach zero and vsock_sk_destruct() run. The `rejected`
flag and its pending_work handling can then be removed. The receive
path is not touched, so there is no re-locking and no deadlock.
I verified this on ARM64 QEMU. On linux v6.6.y (where kmemleak can
see the leak) with the syzbot reproducer:
- before: 6 creates / 4 destructs (2 leaked); kmemleak reports the
cascade;
- after: 6 creates / 6 destructs (0 leaked); kmemleak clean;
- 50-iter normal server and 50-iter same-port-reconnect tests both
pass 50/50 with zero leaks, no double-put warnings.
On mainline, kmemleak stays silent (see above) but create/destruct
accounting confirms the same leak before the fix; the fix is
code-identical across v6.6.y and mainline (same recv_listen/accept
paths).
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.
== Trigger, for completeness ==
The reproducer's atypical-but-legal sequence is what sets
listener->sk_err: a socket is connect()ed (leaving sk_err set, since
vsock_connect() only clears it at the start of a new connect) and then
turned into a listener:
fd = socket(AF_VSOCK, SOCK_STREAM, 0);
bind(fd, ...);
connect(fd, &(VMADDR_CID_LOCAL, ...)); /* leaves sk_err set */
listen(fd, 5);
/* a peer connects to fd; the child created is later rejected */
accept4(fd, ...);
Standard servers (listen before any connect on the same fd) don't hit
it, which is why this went ~2.5 years between the offending commit and
the syzbot report.
[1] https://lore.kernel.org/all/20260605191922.12720-1-divyakm@unc.edu/
[2] https://ci.syzbot.org/series/76f40e62-5a21-46d4-a636-10f0ec9c5040
Thanks.
> <3> 3913 Yes INFO: rcu detected stall in do_idle
> https://syzkaller.appspot.com/bug?extid=385468161961cee80c31
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> To disable reminders for individual bugs, reply with the following command:
> #syz set <Ref> no-reminders
>
> To change bug's subsystems, reply with:
> #syz set <Ref> subsystems: new-subsystem
>
> You may send multiple commands in a single email message.
^ permalink raw reply
* [PATCH v3 0/2] tools: Fix tools/virtio test build
From: Yichong Chen @ 2026-07-02 3:03 UTC (permalink / raw)
To: mst, jasowang, xuanzhuo, eperezma, akpm
Cc: sj, rppt, ljs, pabeni, chenyichong, virtualization, linux-kernel
Hi,
This series fixes build failures hit by:
make -C tools/virtio test
It is based on linux-next commit:
commit 3d5670d672ae ("Add linux-next specific files for 20260626")
Patch 1 adds tools/virtio compatibility definitions needed by current
virtio headers when building the tools/virtio tests. Patch 2 makes
tools/include/linux/overflow.h include stdint.h for SIZE_MAX, which is
used by its size helper functions.
With the series applied, make -C tools/virtio test builds virtio_test,
vringh_test and vhost_net_test successfully.
Tested on x86_64 and arm64 with:
make -C tools/virtio clean
make -C tools/virtio test
Changes in v3:
- Move the stdint.h include inside the overflow.h include guard, as SJ
suggested.
- Add Tested-by from SJ Park to patch 1.
Changes in v2:
- Rebase and retest on linux-next.
- Add the missing asm/percpu_types.h compat header reported by Eugenio.
- Keep the tools/virtio compat definitions aligned with current
virtio_features.h helpers.
- Drop the slab.h kmalloc_obj/kmalloc_objs change because linux-next
already defines them in tools/virtio/linux/kernel.h.
Yichong Chen (2):
tools/virtio: Add missing compat definitions for vhost_net_test
tools/include: Include stdint.h for SIZE_MAX in overflow.h
tools/include/linux/overflow.h | 2 +
tools/virtio/asm/percpu_types.h | 7 +++
tools/virtio/linux/completion.h | 9 ++++
tools/virtio/linux/device.h | 1 +
tools/virtio/linux/dma-mapping.h | 1 +
tools/virtio/linux/mod_devicetable.h | 14 +++++
tools/virtio/linux/virtio_features.h | 79 ++++++++++++++++++++++++++++
7 files changed, 113 insertions(+)
create mode 100644 tools/virtio/asm/percpu_types.h
create mode 100644 tools/virtio/linux/completion.h
create mode 100644 tools/virtio/linux/mod_devicetable.h
create mode 100644 tools/virtio/linux/virtio_features.h
--
2.51.0
^ permalink raw reply
* [PATCH v3 2/2] tools/include: Include stdint.h for SIZE_MAX in overflow.h
From: Yichong Chen @ 2026-07-02 3:03 UTC (permalink / raw)
To: mst, jasowang, xuanzhuo, eperezma, akpm
Cc: sj, rppt, ljs, pabeni, chenyichong, virtualization, linux-kernel
In-Reply-To: <20260702030358.308155-1-chenyichong@uniontech.com>
tools/include/linux/overflow.h uses SIZE_MAX in its size helper
functions.
Include stdint.h so tools users that include overflow.h without another
SIZE_MAX provider can build.
Signed-off-by: Yichong Chen <chenyichong@uniontech.com>
---
tools/include/linux/overflow.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/include/linux/overflow.h b/tools/include/linux/overflow.h
index 3427d7880326..9d30ae0dbd1d 100644
--- a/tools/include/linux/overflow.h
+++ b/tools/include/linux/overflow.h
@@ -2,6 +2,8 @@
#ifndef __LINUX_OVERFLOW_H
#define __LINUX_OVERFLOW_H
+#include <stdint.h>
+
#include <linux/compiler.h>
/*
--
2.51.0
^ permalink raw reply related
* [PATCH v3 1/2] tools/virtio: Add missing compat definitions for vhost_net_test
From: Yichong Chen @ 2026-07-02 3:03 UTC (permalink / raw)
To: mst, jasowang, xuanzhuo, eperezma, akpm
Cc: sj, rppt, ljs, pabeni, chenyichong, virtualization, linux-kernel
In-Reply-To: <20260702030358.308155-1-chenyichong@uniontech.com>
vhost_net_test builds virtio_ring.c in userspace.
Recent virtio headers pull in helper headers that are not provided by
the tools/virtio compatibility layer, including asm/percpu_types.h,
linux/completion.h, linux/mod_devicetable.h and linux/virtio_features.h.
Add the missing compat definitions and the DMA attribute used by the
current virtio ring code.
Signed-off-by: Yichong Chen <chenyichong@uniontech.com>
Tested-by: SJ Park <sj@kernel.org>
---
tools/virtio/asm/percpu_types.h | 7 +++
tools/virtio/linux/completion.h | 9 ++++
tools/virtio/linux/device.h | 1 +
tools/virtio/linux/dma-mapping.h | 1 +
tools/virtio/linux/mod_devicetable.h | 14 +++++
tools/virtio/linux/virtio_features.h | 79 ++++++++++++++++++++++++++++
6 files changed, 111 insertions(+)
create mode 100644 tools/virtio/asm/percpu_types.h
create mode 100644 tools/virtio/linux/completion.h
create mode 100644 tools/virtio/linux/mod_devicetable.h
create mode 100644 tools/virtio/linux/virtio_features.h
diff --git a/tools/virtio/asm/percpu_types.h b/tools/virtio/asm/percpu_types.h
new file mode 100644
index 000000000000..4eb53d93c099
--- /dev/null
+++ b/tools/virtio/asm/percpu_types.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_PERCPU_TYPES_H
+#define _ASM_PERCPU_TYPES_H
+
+#define __percpu_qual
+
+#endif /* _ASM_PERCPU_TYPES_H */
diff --git a/tools/virtio/linux/completion.h b/tools/virtio/linux/completion.h
new file mode 100644
index 000000000000..5e54b679721b
--- /dev/null
+++ b/tools/virtio/linux/completion.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_COMPLETION_H
+#define _LINUX_COMPLETION_H
+
+struct completion {
+ unsigned int done;
+};
+
+#endif /* _LINUX_COMPLETION_H */
diff --git a/tools/virtio/linux/device.h b/tools/virtio/linux/device.h
index 075c2140d975..abf100cb0023 100644
--- a/tools/virtio/linux/device.h
+++ b/tools/virtio/linux/device.h
@@ -1,4 +1,5 @@
#ifndef LINUX_DEVICE_H
+#define LINUX_DEVICE_H
struct device {
void *parent;
diff --git a/tools/virtio/linux/dma-mapping.h b/tools/virtio/linux/dma-mapping.h
index 8d1a16cb20db..b9fc5e8338e3 100644
--- a/tools/virtio/linux/dma-mapping.h
+++ b/tools/virtio/linux/dma-mapping.h
@@ -61,5 +61,6 @@ enum dma_data_direction {
#define DMA_MAPPING_ERROR (~(dma_addr_t)0)
#define DMA_ATTR_CPU_CACHE_CLEAN (1UL << 11)
+#define DMA_ATTR_DEBUGGING_IGNORE_CACHELINES 0
#endif
diff --git a/tools/virtio/linux/mod_devicetable.h b/tools/virtio/linux/mod_devicetable.h
new file mode 100644
index 000000000000..3ba594b8229d
--- /dev/null
+++ b/tools/virtio/linux/mod_devicetable.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_MOD_DEVICETABLE_H
+#define _LINUX_MOD_DEVICETABLE_H
+
+#include <linux/types.h>
+
+struct virtio_device_id {
+ __u32 device;
+ __u32 vendor;
+};
+
+#define VIRTIO_DEV_ANY_ID 0xffffffff
+
+#endif /* _LINUX_MOD_DEVICETABLE_H */
diff --git a/tools/virtio/linux/virtio_features.h b/tools/virtio/linux/virtio_features.h
new file mode 100644
index 000000000000..04cbb9622ec7
--- /dev/null
+++ b/tools/virtio/linux/virtio_features.h
@@ -0,0 +1,79 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_VIRTIO_FEATURES_H
+#define _LINUX_VIRTIO_FEATURES_H
+
+#include <linux/bug.h>
+#include <linux/string.h>
+#include <linux/types.h>
+
+#define VIRTIO_FEATURES_U64S 2
+#define VIRTIO_FEATURES_BITS (VIRTIO_FEATURES_U64S * 64)
+
+#define VIRTIO_BIT(b) (1ULL << ((b) & 0x3f))
+#define VIRTIO_U64(b) ((b) >> 6)
+
+#define VIRTIO_DECLARE_FEATURES(name) \
+ union { \
+ u64 name; \
+ u64 name##_array[VIRTIO_FEATURES_U64S];\
+ }
+
+static inline bool virtio_features_chk_bit(unsigned int bit)
+{
+ return bit < VIRTIO_FEATURES_BITS;
+}
+
+static inline bool virtio_features_test_bit(const u64 *features,
+ unsigned int bit)
+{
+ return virtio_features_chk_bit(bit) &&
+ !!(features[VIRTIO_U64(bit)] & VIRTIO_BIT(bit));
+}
+
+static inline void virtio_features_set_bit(u64 *features, unsigned int bit)
+{
+ if (virtio_features_chk_bit(bit))
+ features[VIRTIO_U64(bit)] |= VIRTIO_BIT(bit);
+}
+
+static inline void virtio_features_clear_bit(u64 *features, unsigned int bit)
+{
+ if (virtio_features_chk_bit(bit))
+ features[VIRTIO_U64(bit)] &= ~VIRTIO_BIT(bit);
+}
+
+static inline void virtio_features_zero(u64 *features)
+{
+ memset(features, 0, sizeof(features[0]) * VIRTIO_FEATURES_U64S);
+}
+
+static inline void virtio_features_from_u64(u64 *features, u64 from)
+{
+ virtio_features_zero(features);
+ features[0] = from;
+}
+
+static inline bool virtio_features_equal(const u64 *f1, const u64 *f2)
+{
+ int i;
+
+ for (i = 0; i < VIRTIO_FEATURES_U64S; ++i)
+ if (f1[i] != f2[i])
+ return false;
+ return true;
+}
+
+static inline void virtio_features_copy(u64 *to, const u64 *from)
+{
+ memcpy(to, from, sizeof(to[0]) * VIRTIO_FEATURES_U64S);
+}
+
+static inline void virtio_features_andnot(u64 *to, const u64 *f1, const u64 *f2)
+{
+ int i;
+
+ for (i = 0; i < VIRTIO_FEATURES_U64S; i++)
+ to[i] = f1[i] & ~f2[i];
+}
+
+#endif /* _LINUX_VIRTIO_FEATURES_H */
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v2 2/3] drm/virtio: honor blob_alignment requirements
From: Michael S. Tsirkin @ 2026-07-02 4:03 UTC (permalink / raw)
To: Alyssa Ross
Cc: Sergio Lopez, Chia-I Wu, Jason Wang, Eugenio Pérez,
Xuan Zhuo, linux-kernel, Simona Vetter, Dmitry Osipenko,
Thomas Zimmermann, David Airlie, Gurchetan Singh, Gerd Hoffmann,
virtualization, dri-devel, Maxime Ripard, Maarten Lankhorst
In-Reply-To: <akT1XEW766c7Imst@mbp.qyliss.net>
On Wed, Jul 01, 2026 at 01:10:30PM +0200, Alyssa Ross wrote:
> On Tue, Apr 28, 2026 at 09:44:49PM +0200, Sergio Lopez wrote:
> > If VIRTIO_GPU_F_BLOB_ALIGNMENT has been negotiated, blob size must be
> > aligned to blob_alignment. Validate this in verify_blob() so that
> > invalid requests are rejected early.
> >
> > Signed-off-by: Sergio Lopez <slp@redhat.com>
>
> FYI: this change breaks crosvm, which is squatting the 5 and 6 values
> of VIRTIO_GPU_F_* with different meanings. I've reported it as a
> crosvm bug, so hopefully it can be taken care of there.
>
> https://issuetracker.google.com/issues/529852979
Move fast and beak things, then it takes a wile to fix them)
Do you understand who uses it maybe? Maybe if there's a PR
for both sides it will be handled faster.
> > ---
> > drivers/gpu/drm/virtio/virtgpu_ioctl.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> > index c33c057365f8..d0c4edf1eaf4 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> > @@ -489,6 +489,11 @@ static int verify_blob(struct virtio_gpu_device *vgdev,
> > params->size = rc_blob->size;
> > params->blob = true;
> > params->blob_flags = rc_blob->blob_flags;
> > +
> > + if (vgdev->has_blob_alignment &&
> > + !IS_ALIGNED(params->size, vgdev->blob_alignment))
> > + return -EINVAL;
> > +
> > return 0;
> > }
> >
> > --
> > 2.53.0
> >
^ permalink raw reply
* Re: [PATCH] drm/virtio: defer hotplug event from dequeue worker to avoid deadlock
From: Ryosuke Yasuoka @ 2026-07-02 7:12 UTC (permalink / raw)
To: Hillf Danton
Cc: Dmitry Osipenko, Dmitry Baryshkov, Javier Martinez Canillas,
dri-devel, virtualization, linux-kernel
In-Reply-To: <20260701234301.361-1-hdanton@sina.com>
On 02/07/2026 07:43, Hillf Danton wrote:
> On Wed, 1 Jul 2026 09:23:05 +0000 Ryosuke Yasuoka wrote:
>>On 30/06/2026 16:46, Dmitry Osipenko wrote:
>>> Could you please move drm_kms_helper_hotplug_event() to virtio_gpu_init(),
>>> placing it after wait_event_timeout(display_info_pending)? This will avoid
>>> additional work_struct that otherwise needs to be cancelled in
>>> virtio_gpu_init() on the timeout.
>>
>>IIUC, moving the drm_kms_helper_hotplug_event() and _hpd_irq_event()
>>into virtio_gpu_init() after wait_event_timeout() would not prevent the
>>issue.
>>
>>Looking at the syzbot call traces[1][2], the deadlock occurs during
>>drm_client_setup(), which runs after virtio_gpu_init() has already
>>returned. The display_info_cb that triggers the deadlock is called from
>>the dequeue worker while drm_client_register() holds clientlist_mutex.
>>
>>Thread A:
>>virtio_gpu_probe()
>> -> virtio_gpu_init() // sends GET_DISPLAY_INFO and waits up to 5s
>> -> drm_dev_register()
>> -> drm_client_setup() // deadlock happens HERE
>> -> drm_client_register() // holds clientlist_mutex
>> ...
>> -> virtio_gpu_queue_fenced_ctrl_buffer()
>> -> wait_event() // waits for free space
>>
>>Thread B:
>>virtio_gpu_dequeue_ctrl_func()
>> -> reclaim_vbufs() // make free space
>
> I wonder if the deadlock could be cured by alternatively adding a wakeup
> before the responce cb, given that free space is available.
Thanks for your comment. I agree that moving wake_up() before response
cb would help in most cases, and I think it is a reasonable aproach.
However, there are a few rare scenarios where the deadlock can still
occur:
1. If reclaim_vbufs() does not free enough slots to satisfy
num_free >= elemcnt, wake_up() fires but the wait_event() condition
evaluates false. Thread A remains asleep holding clientlist_mutex, and
the dequeue worker proceeds to display_info_cb which blocks on
clientlist_mutex.
2. Even if enough slots are freed, there is a small window between
wait_event() returning and Thread A acquiring spin_lock(&qlock) at the
"goto again" path in virtio_gpu_queue_ctrl_sgs(). Another thread can
consume the freed slots during this window, causing Thread A to loop
back to wait_event() still holding clientlist_mutex.
3. Reordering wake_up() before resp_cb inverts the natural "process
response, then signal completion" pattern, which could introduce subtle
issues if a future resp_cb depends on side effects that should happen
after wake_up(), I believe.
These scenarios are likely rare in practice, but the schedule_work()
approach avoids all of them entirely by ensuring the dequeue worker
never touches clientlist_mutex. It also follows the same pattern
already used by config_changed_work in this driver.
Best regards
Ryosuke
>
>> -> resp_cb()
>> -> virtio_gpu_cmd_get_display_info_cb
>> -> drm_helper_hpd_irq_event()
>> -> drm_kms_helper_hotplug_event()
>> -> drm_client_dev_hotplug() // need to lock clientlist_mutex
>> -> wake_up() // never reached
>>
>>IIUC the hotplug notification in display_info_cb is needed because it
>>notifies DRM after updating by the callback with fresh data from the host.
>>
>>This work_struct ensures display_info_cb never blocks on
>>clientlist_mutex in the dequeue worker, while preserving the hotplug
>>notification with fresh data.
>>
>>[1] https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224
>>[2] https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e
>>
>>Best regards,
>>Ryosuke
^ permalink raw reply
* Re: [PATCH 01/13] mm: introduce vma_flags_can_grow() and vma_can_grow()
From: Lance Yang @ 2026-07-02 7:27 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
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: <f2e8c32515d328db62279cc8bab8398ea278d74f.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:24PM +0100, Lorenzo Stoakes wrote:
>These test whether the VMA has stack sematics, i.e. is able to grow upwards
>or downwards depending on the architecture.
>
>In order to account for arches which do not support upward-growing stacks,
>introduce VMA_GROWSUP whose definition depends on the architecture
>supporting it, and use vma_flags_test_single_mask() in vma_flags_can_grow()
>to account for this.
>
>Update the VMA userland tests to reflect the changes
>
>No functional change intended.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
Nice cleanup! Feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
^ permalink raw reply
* Re: [PATCH] drm/virtio: defer hotplug event from dequeue worker to avoid deadlock
From: Hillf Danton @ 2026-07-02 8:25 UTC (permalink / raw)
To: Ryosuke Yasuoka
Cc: Dmitry Osipenko, Dmitry Baryshkov, Javier Martinez Canillas,
dri-devel, virtualization, linux-kernel
In-Reply-To: <18be678e97322160.8f56a0770e5621ab.8d175eba8a62d6be@ryasuoka-thinkpadx1carbongen9.tokyo.csb>
On Thu, 2 Jul 2026 07:12:44 +0000 Ryosuke Yasuoka wrote:
>On 02/07/2026 07:43, Hillf Danton wrote:
>> On Wed, 1 Jul 2026 09:23:05 +0000 Ryosuke Yasuoka wrote:
>>>On 30/06/2026 16:46, Dmitry Osipenko wrote:
>>>> Could you please move drm_kms_helper_hotplug_event() to virtio_gpu_init(),
>>>> placing it after wait_event_timeout(display_info_pending)? This will avoid
>>>> additional work_struct that otherwise needs to be cancelled in
>>>> virtio_gpu_init() on the timeout.
>>>
>>>IIUC, moving the drm_kms_helper_hotplug_event() and _hpd_irq_event()
>>>into virtio_gpu_init() after wait_event_timeout() would not prevent the
>>>issue.
>>>
>>>Looking at the syzbot call traces[1][2], the deadlock occurs during
>>>drm_client_setup(), which runs after virtio_gpu_init() has already
>>>returned. The display_info_cb that triggers the deadlock is called from
>>>the dequeue worker while drm_client_register() holds clientlist_mutex.
>>>
>>>Thread A:
>>>virtio_gpu_probe()
>>> -> virtio_gpu_init() // sends GET_DISPLAY_INFO and waits up to 5s
>>> -> drm_dev_register()
>>> -> drm_client_setup() // deadlock happens HERE
>>> -> drm_client_register() // holds clientlist_mutex
>>> ...
>>> -> virtio_gpu_queue_fenced_ctrl_buffer()
>>> -> wait_event() // waits for free space
>>>
>>>Thread B:
>>>virtio_gpu_dequeue_ctrl_func()
>>> -> reclaim_vbufs() // make free space
>>
>> I wonder if the deadlock could be cured by alternatively adding a wakeup
>> before the responce cb, given that free space is available.
>
>Thanks for your comment. I agree that moving wake_up() before response
>cb would help in most cases, and I think it is a reasonable aproach.
>However, there are a few rare scenarios where the deadlock can still
>occur:
>
>1. If reclaim_vbufs() does not free enough slots to satisfy
>num_free >= elemcnt, wake_up() fires but the wait_event() condition
>evaluates false. Thread A remains asleep holding clientlist_mutex, and
>the dequeue worker proceeds to display_info_cb which blocks on
>clientlist_mutex.
task0 task1
lock clientlist_mutex
wait_event(for enough free slots)
free some slots
lock clientlist_mutex
unlock clientlist_mutex
wakeup
deadlock
The clientlist_mutex will not be released without enough slots freed, so more
free slots and wakeup are needed to cure the deadlock, with nothing to do with
acquiring the mutex in the workqueue context.
Your workqueue approach works by removing the dependence of wakeup on acquiring
the mutex, without enough free slots guaranteed.
In short, wakeup before acquiring the mutex is the right thing to do, I mean
it is not the only one at all.
>2. Even if enough slots are freed, there is a small window between
>wait_event() returning and Thread A acquiring spin_lock(&qlock) at the
>"goto again" path in virtio_gpu_queue_ctrl_sgs(). Another thread can
>consume the freed slots during this window, causing Thread A to loop
>back to wait_event() still holding clientlist_mutex.
Ditto
>3. Reordering wake_up() before resp_cb inverts the natural "process
>response, then signal completion" pattern, which could introduce subtle
>issues if a future resp_cb depends on side effects that should happen
>after wake_up(), I believe.
>
Different taste
>These scenarios are likely rare in practice, but the schedule_work()
>approach avoids all of them entirely by ensuring the dequeue worker
>never touches clientlist_mutex. It also follows the same pattern
>already used by config_changed_work in this driver.
>
>Best regards
>Ryosuke
>
>>
>>> -> resp_cb()
>>> -> virtio_gpu_cmd_get_display_info_cb
>>> -> drm_helper_hpd_irq_event()
>>> -> drm_kms_helper_hotplug_event()
>>> -> drm_client_dev_hotplug() // need to lock clientlist_mutex
>>> -> wake_up() // never reached
>>>
>>>IIUC the hotplug notification in display_info_cb is needed because it
>>>notifies DRM after updating by the callback with fresh data from the host.
>>>
>>>This work_struct ensures display_info_cb never blocks on
>>>clientlist_mutex in the dequeue worker, while preserving the hotplug
>>>notification with fresh data.
>>>
>>>[1] https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224
>>>[2] https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e
>>>
>>>Best regards,
>>>Ryosuke
^ permalink raw reply
* Re: [PATCH v2 2/3] drm/virtio: honor blob_alignment requirements
From: Alyssa Ross @ 2026-07-02 8:53 UTC (permalink / raw)
To: Gurchetan Singh, Michael S. Tsirkin
Cc: Sergio Lopez, Chia-I Wu, Jason Wang, Eugenio Pérez,
Xuan Zhuo, linux-kernel, Simona Vetter, Dmitry Osipenko,
Thomas Zimmermann, David Airlie, Gerd Hoffmann, virtualization,
dri-devel, Maxime Ripard, Maarten Lankhorst
In-Reply-To: <20260702000144-mutt-send-email-mst@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]
"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Wed, Jul 01, 2026 at 01:10:30PM +0200, Alyssa Ross wrote:
>> On Tue, Apr 28, 2026 at 09:44:49PM +0200, Sergio Lopez wrote:
>> > If VIRTIO_GPU_F_BLOB_ALIGNMENT has been negotiated, blob size must be
>> > aligned to blob_alignment. Validate this in verify_blob() so that
>> > invalid requests are rejected early.
>> >
>> > Signed-off-by: Sergio Lopez <slp@redhat.com>
>>
>> FYI: this change breaks crosvm, which is squatting the 5 and 6 values
>> of VIRTIO_GPU_F_* with different meanings. I've reported it as a
>> crosvm bug, so hopefully it can be taken care of there.
>>
>> https://issuetracker.google.com/issues/529852979
>
> Move fast and beak things, then it takes a wile to fix them)
> Do you understand who uses it maybe? Maybe if there's a PR
> for both sides it will be handled faster.
I have no idea where the device side is. Doesn't seem to be in the
Chromium kernel tree, nor are there any patches for it in Chromium
Gerrit. Maybe Gurchetan can shed some light?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [PATCH net 1/2] vsock/virtio: collapse receive queue under memory pressure
From: Stefano Garzarella @ 2026-07-02 8:56 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: <akVBmydgSd0Eb46/@devvm29614.prn0.facebook.com>
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.
Maybe it's necessary for the eBPF path?
In any case, I can add it, but if you can help me better understand what
it prevents, that will also help me add a comment above it.
Thanks,
Stefano
^ permalink raw reply
* Re: [PATCH 00/32] x86/msr: Drop 32-bit MSR interfaces
From: Ingo Molnar @ 2026-07-02 10:07 UTC (permalink / raw)
To: Sean Christopherson
Cc: Arnd Bergmann, Juergen Gross, linux-kernel, linux-pm,
linux-edac@vger.kernel.org, x86, linux-acpi, kvm, linux-coco,
linux-pci, virtualization, linux-ide, dri-devel, linux-fbdev,
linux-crypto, open list:GPIO SUBSYSTEM, linux-hyperv, linux-hwmon,
linux-perf-users, linux-mtd, platform-driver-x86,
Rafael J . Wysocki, Daniel Lezcano, Zhang Rui,
lukasz.luba@arm.com, Jason Baron, Borislav Petkov, Tony Luck,
Yazen Ghannam, Len Brown, Pavel Machek, Thomas Gleixner,
Ingo Molnar, Dave Hansen, H. Peter Anvin, Paolo Bonzini,
Kirill A. Shutemov, Rick Edgecombe, Pu Wen, Bjorn Helgaas,
Ajay Kaher, Alexey Makhalov, Broadcom internal kernel review list,
Viresh Kumar, Reinette Chatre, Dave Martin, James Morse,
Babu Moger, Tony W Wang-oc, Damien Le Moal, Niklas Cassel,
Dave Airlie, Helge Deller, linux-geode, Olivia Mackall,
Herbert Xu, Linus Walleij, Bartosz Golaszewski,
Greg Kroah-Hartman, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Guenter Roeck, Peter Zijlstra,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Josh Poimboeuf, Pawan Gupta, Vitaly Kuznetsov,
Andy Lutomirski, Boris Ostrovsky, Huang Rui, Mario Limonciello,
Perry Yuan, K Prateek Nayak, srinivas.pandruvada@linux.intel.com,
Artem Bityutskiy, Artem Bityutskiy, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, Ashok Raj, Hans de Goede,
Ilpo Järvinen, Rajneesh Bhardwaj, David E Box, xen-devel
In-Reply-To: <akQR9YMtMHReJTfB@google.com>
* Sean Christopherson <seanjc@google.com> wrote:
> > Note that the individual patches are IMO significantly easier to review
> > through the actual 32-bit => 64-bit variable assignment changes done
> > in isolation (which sometimes include minor cleanups), while
> > the Coccinelle semantic patch:
> >
> > { a(b,c) => c = a(b) }
> >
> > which changes both the function signature and the order of terms as
> > well, is just a single add-on treewide patch.
>
> Is the plan for subsystem maintainers to pick up the relevant patches,
> and then do the treewide change one release cycle later?
I'll try to keep the patches in a single tree (tip:x86/msr)
in the hope of not prolonging the pain two cycles - but it's
of course fine for maintainers to pick up the patches too
(most of them are standalone), we'll sort it all out in the end.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 00/32] x86/msr: Drop 32-bit MSR interfaces
From: Juergen Gross @ 2026-07-02 11:03 UTC (permalink / raw)
To: Ingo Molnar, Sean Christopherson
Cc: Arnd Bergmann, linux-kernel, linux-pm, linux-edac@vger.kernel.org,
x86, linux-acpi, kvm, linux-coco, linux-pci, virtualization,
linux-ide, dri-devel, linux-fbdev, linux-crypto,
open list:GPIO SUBSYSTEM, linux-hyperv, linux-hwmon,
linux-perf-users, linux-mtd, platform-driver-x86,
Rafael J . Wysocki, Daniel Lezcano, Zhang Rui,
lukasz.luba@arm.com, Jason Baron, Borislav Petkov, Tony Luck,
Yazen Ghannam, Len Brown, Pavel Machek, Thomas Gleixner,
Ingo Molnar, Dave Hansen, H. Peter Anvin, Paolo Bonzini,
Kirill A. Shutemov, Rick Edgecombe, Pu Wen, Bjorn Helgaas,
Ajay Kaher, Alexey Makhalov, Broadcom internal kernel review list,
Viresh Kumar, Reinette Chatre, Dave Martin, James Morse,
Babu Moger, Tony W Wang-oc, Damien Le Moal, Niklas Cassel,
Dave Airlie, Helge Deller, linux-geode, Olivia Mackall,
Herbert Xu, Linus Walleij, Bartosz Golaszewski,
Greg Kroah-Hartman, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Guenter Roeck, Peter Zijlstra,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Josh Poimboeuf, Pawan Gupta, Vitaly Kuznetsov,
Andy Lutomirski, Boris Ostrovsky, Huang Rui, Mario Limonciello,
Perry Yuan, K Prateek Nayak, srinivas.pandruvada@linux.intel.com,
Artem Bityutskiy, Artem Bityutskiy, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, Ashok Raj, Hans de Goede,
Ilpo Järvinen, Rajneesh Bhardwaj, David E Box, xen-devel
In-Reply-To: <akY4U0jUZm4HOGZ_@gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 1367 bytes --]
On 02.07.26 12:07, Ingo Molnar wrote:
>
> * Sean Christopherson <seanjc@google.com> wrote:
>
>>> Note that the individual patches are IMO significantly easier to review
>>> through the actual 32-bit => 64-bit variable assignment changes done
>>> in isolation (which sometimes include minor cleanups), while
>>> the Coccinelle semantic patch:
>>>
>>> { a(b,c) => c = a(b) }
>>>
>>> which changes both the function signature and the order of terms as
>>> well, is just a single add-on treewide patch.
>>
>> Is the plan for subsystem maintainers to pick up the relevant patches,
>> and then do the treewide change one release cycle later?
>
> I'll try to keep the patches in a single tree (tip:x86/msr)
> in the hope of not prolonging the pain two cycles - but it's
> of course fine for maintainers to pick up the patches too
> (most of them are standalone), we'll sort it all out in the end.
Ingo, would you be fine with me posting patch updates just as replies to the
original patch emails? This would speed things up, as I wouldn't need to wait
for more review input of all the patches before sending out new versions.
As the patches are (mostly) standalone, this should not cause any weird
problems.
The last two patches might need updates, but those can be applied only after
the rest has been accepted anyway.
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply
* Re: [PATCH 02/13] mm/vma: update do_mmap() to use vma_flags_t
From: Lance Yang @ 2026-07-02 11:15 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
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 08:25:25PM +0100, 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>
>---
Not exactly a small one :) I stared at this patch for a while, hopefully
don't miss anythig ...
Just one tiny nit below. Overall, LGTM, feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
[...]
>diff --git a/mm/mmap.c b/mm/mmap.c
>index 46174e706bbe..547352183214 100644
>--- a/mm/mmap.c
>+++ b/mm/mmap.c
[...]
>@@ -488,23 +496,27 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
> * Check to see if we are violating any seals and update VMA
> * flags if necessary to avoid future seal violations.
> */
>- err = memfd_check_seals_mmap(file, &vm_flags);
>+ err = memfd_check_seals_mmap(file, &vma_flags);
> if (err)
> return (unsigned long)err;
> } else {
> switch (flags & MAP_TYPE) {
> case MAP_SHARED:
>- if (vm_flags & (VM_GROWSDOWN|VM_GROWSUP))
>+ if (vma_flags_can_grow(&vma_flags))
> return -EINVAL;
> /*
> * Ignore pgoff.
> */
> pgoff = 0;
>- vm_flags |= VM_SHARED | VM_MAYSHARE;
>+ vma_flags_set(&vma_flags, VMA_SHARED_BIT, VMA_MAYSHARE_BIT);
> break;
>- case MAP_DROPPABLE:
>- if (VM_DROPPABLE == VM_NONE)
>+ 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;
Old code checked VM_GROWSDOWN|VM_GROWSUP before seting VM_DROPPABLE. New
code flips that around. Hmm, shouldn't master, just made me look twice ;)
Maybe keep old order?
Cheers, Lance
>-
> /*
> * If the pages can be dropped, then it doesn't make
> * sense to reserve them.
> */
>- vm_flags |= VM_NORESERVE;
>+ vma_flags_set(&vma_flags, VMA_NORESERVE_BIT);
>
> /*
> * Likewise, they're volatile enough that they
> * shouldn't survive forks or coredumps.
> */
>- vm_flags |= VM_WIPEONFORK | VM_DONTDUMP;
>+ vma_flags_set(&vma_flags, VMA_WIPEONFORK_BIT,
>+ VMA_DONTDUMP_BIT);
>+
> fallthrough;
>+ }
> case MAP_PRIVATE:
> /*
> * Set pgoff according to addr for anon_vma.
[...]
^ permalink raw reply
* Re: [PATCH] drm/virtio: defer hotplug event from dequeue worker to avoid deadlock
From: Dmitry Osipenko @ 2026-07-02 11:26 UTC (permalink / raw)
To: Ryosuke Yasuoka, David Airlie, Gerd Hoffmann, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Dmitry Baryshkov, Javier Martinez Canillas
Cc: dri-devel, virtualization, linux-kernel
In-Reply-To: <18be2016e26ade27.a6e9e2496bc1f978.9bc3a62421115997@ryasuoka-thinkpadx1carbongen9.tokyo.csb>
On 7/1/26 12:23, Ryosuke Yasuoka wrote:
>
>
> On 30/06/2026 16:46, Dmitry Osipenko wrote:
>> Hi,
>>
>> On 6/30/26 12:16, Ryosuke Yasuoka wrote:
>>> A probe-time deadlock can occur between the dequeue worker and
>>> drm_client_register(). During probe, drm_client_register() holds
>>> clientlist_mutex and calls the fbdev hotplug callback, which triggers an
>>> atomic commit that ends up sleeping in virtio_gpu_queue_ctrl_sgs()
>>> waiting for virtqueue space. The dequeue worker that would free that
>>> space calls virtio_gpu_cmd_get_display_info_cb(), which invokes
>>> drm_kms_helper_hotplug_event() -> drm_client_dev_hotplug(), attempting
>>> to acquire the same clientlist_mutex. Since wake_up() is only called
>>> after the resp_cb loop, the probe thread is never woken and both threads
>>> deadlock.
>>>
>>> Fix this by deferring the hotplug notification from
>>> virtio_gpu_cmd_get_display_info_cb() to a separate work item. The
>>> display data (outputs[i].info) is still updated synchronously in the
>>> callback, and the deferred work only triggers a re-probe notification to
>>> DRM clients.
>>>
>>> Fixes: 27655b9bb9f0 ("drm/client: Send hotplug event after registering a client")
>>> Closes: https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224
>>> Closes: https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e
>>> Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com>
>>> ---
>>> drivers/gpu/drm/virtio/virtgpu_drv.h | 3 +++
>>> drivers/gpu/drm/virtio/virtgpu_kms.c | 3 +++
>>> drivers/gpu/drm/virtio/virtgpu_vq.c | 12 ++++++++++--
>>> 3 files changed, 16 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h
>>> index 7449907754a4..27ffa4697ae9 100644
>>> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
>>> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
>>> @@ -264,6 +264,8 @@ struct virtio_gpu_device {
>>>
>>> struct work_struct config_changed_work;
>>>
>>> + struct work_struct hotplug_work;
>>> +
>>> struct work_struct obj_free_work;
>>> spinlock_t obj_free_lock;
>>> struct list_head obj_free_list;
>>> @@ -350,6 +352,7 @@ void virtio_gpu_cmd_transfer_to_host_2d(struct virtio_gpu_device *vgdev,
>>> uint32_t x, uint32_t y,
>>> struct virtio_gpu_object_array *objs,
>>> struct virtio_gpu_fence *fence);
>>> +void virtio_gpu_hotplug_work_func(struct work_struct *work);
>>> void virtio_gpu_panic_cmd_resource_flush(struct virtio_gpu_device *vgdev,
>>> uint32_t resource_id,
>>> uint32_t x, uint32_t y,
>>> diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c
>>> index cfde9f573df6..cfb532ba43a4 100644
>>> --- a/drivers/gpu/drm/virtio/virtgpu_kms.c
>>> +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
>>> @@ -154,6 +154,8 @@ int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev)
>>> INIT_WORK(&vgdev->config_changed_work,
>>> virtio_gpu_config_changed_work_func);
>>>
>>> + INIT_WORK(&vgdev->hotplug_work, virtio_gpu_hotplug_work_func);
>>> +
>>> INIT_WORK(&vgdev->obj_free_work,
>>> virtio_gpu_array_put_free_work);
>>> INIT_LIST_HEAD(&vgdev->obj_free_list);
>>> @@ -293,6 +295,7 @@ void virtio_gpu_deinit(struct drm_device *dev)
>>> flush_work(&vgdev->obj_free_work);
>>> flush_work(&vgdev->ctrlq.dequeue_work);
>>> flush_work(&vgdev->cursorq.dequeue_work);
>>> + flush_work(&vgdev->hotplug_work);
>>> flush_work(&vgdev->config_changed_work);
>>> virtio_reset_device(vgdev->vdev);
>>> vgdev->vdev->config->del_vqs(vgdev->vdev);
>>> diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
>>> index 67865810a2e7..084d98f5dc7b 100644
>>> --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
>>> +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
>>> @@ -816,6 +816,15 @@ virtio_gpu_cmd_resource_detach_backing(struct virtio_gpu_device *vgdev,
>>> virtio_gpu_queue_fenced_ctrl_buffer(vgdev, vbuf, fence);
>>> }
>>>
>>> +void virtio_gpu_hotplug_work_func(struct work_struct *work)
>>> +{
>>> + struct virtio_gpu_device *vgdev =
>>> + container_of(work, struct virtio_gpu_device, hotplug_work);
>>> +
>>> + if (!drm_helper_hpd_irq_event(vgdev->ddev))
>>> + drm_kms_helper_hotplug_event(vgdev->ddev);
>>> +}
>>> +
>>> static void virtio_gpu_cmd_get_display_info_cb(struct virtio_gpu_device *vgdev,
>>> struct virtio_gpu_vbuffer *vbuf)
>>> {
>>> @@ -841,8 +850,7 @@ static void virtio_gpu_cmd_get_display_info_cb(struct virtio_gpu_device *vgdev,
>>> spin_unlock(&vgdev->display_info_lock);
>>> wake_up(&vgdev->resp_wq);
>>>
>>> - if (!drm_helper_hpd_irq_event(vgdev->ddev))
>>> - drm_kms_helper_hotplug_event(vgdev->ddev);
>>> + schedule_work(&vgdev->hotplug_work);
>>> }
>>>
>>> static void virtio_gpu_cmd_get_capset_info_cb(struct virtio_gpu_device *vgdev,
>>
>
> Hi,
> Thank you for your review.
>
>> Could you please move drm_kms_helper_hotplug_event() to virtio_gpu_init(), placing it after wait_event_timeout(display_info_pending)? This will avoid additional work_struct that otherwise needs to be cancelled in virtio_gpu_init() on the timeout.
>
> IIUC, moving the drm_kms_helper_hotplug_event() and _hpd_irq_event()
> into virtio_gpu_init() after wait_event_timeout() would not prevent the
> issue.
>
> Looking at the syzbot call traces[1][2], the deadlock occurs during
> drm_client_setup(), which runs after virtio_gpu_init() has already
> returned. The display_info_cb that triggers the deadlock is called from
> the dequeue worker while drm_client_register() holds clientlist_mutex.
>
> Thread A:
> virtio_gpu_probe()
> -> virtio_gpu_init() // sends GET_DISPLAY_INFO and waits up to 5s
You mean that the timeout happens and it's again syzkaller report for a
broken host. A day ago I applied [1] that should fix this "bogus"
syzkaller report.
[1] https://patchwork.freedesktop.org/patch/735301/
--
Best regards,
Dmitry
^ permalink raw reply
* Re: [PATCH 03/13] mm: convert __get_unmapped_area() to use vma_flags_t
From: Lance Yang @ 2026-07-02 11:37 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
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 08:25:26PM +0100, 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>
>---
Nothing suspicious that I could spot :) Feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
^ permalink raw reply
* Re: [PATCH 04/13] mm: update generic_get_unmapped_area[_topdown]() to use vma_flags_t
From: Lance Yang @ 2026-07-02 11:41 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
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 08:25:27PM +0100, 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>
>---
Nothing jumped out at me ;) Feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
^ permalink raw reply
* Re: [PATCH 05/13] mm: prefer mm->def_vma_flags in mm logic
From: Lance Yang @ 2026-07-02 12:10 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
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: <3b4ccdc38819b42ddc79ee5a795831208ac7986c.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:28PM +0100, 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.
>
>No functional change intended.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
> mm/debug.c | 2 +-
> mm/mlock.c | 13 +++++++------
> mm/mmap.c | 11 ++++++-----
> mm/vma.c | 4 ++--
> 4 files changed, 16 insertions(+), 14 deletions(-)
>
>diff --git a/mm/debug.c b/mm/debug.c
>index 497654b36f1a..f0a354a9496a 100644
>--- a/mm/debug.c
>+++ b/mm/debug.c
>@@ -226,7 +226,7 @@ void dump_mm(const struct mm_struct *mm)
> mm->numa_next_scan, mm->numa_scan_offset, mm->numa_scan_seq,
> #endif
> atomic_read(&mm->tlb_flush_pending),
>- mm->def_flags, &mm->def_flags
>+ vma_flags_to_legacy(mm->def_vma_flags), &mm->def_vma_flags
> );
While at it, one thing for later: dump_mm() still assumes one-world VMA
flags. That works today since vma_flags_t is one word. Maybe worth a
BUILD_BUG_ON() here, before that stops being true?
Not a big deal though. Feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
> }
> EXPORT_SYMBOL(dump_mm);
[...]
^ permalink raw reply
* Re: [PATCH 06/13] mm/vma: convert vm_pgprot_modify() to use vma_flags_t and rename
From: Lance Yang @ 2026-07-02 12:21 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
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: <548ba81b2971734d4d2143237ad1465bd1b2f525.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:29PM +0100, 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.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
[...]
>diff --git a/mm/vma.h b/mm/vma.h
>index bcf0c2773449..6a8abb8ae937 100644
>--- a/mm/vma.h
>+++ b/mm/vma.h
>@@ -522,9 +522,11 @@ static inline bool vma_wants_manual_pte_write_upgrade(struct vm_area_struct *vma
> }
>
> #ifdef CONFIG_MMU
>-static inline pgprot_t vm_pgprot_modify(pgprot_t oldprot, vm_flags_t vm_flags)
>+static inline pgprot_t vma_pgprot_modify(pgprot_t oldprot, vma_flags_t vma_flags)
> {
>- return pgprot_modify(oldprot, vm_get_page_prot(vm_flags));
>+ const pgprot_t prot = vma_get_page_prot(vma_flags);
>+
>+ return pgprot_modify(oldprot, prot);
Nit: could this just stay as a single return? something like:
return pgprot_modify(oldprot, vma_get_page_prot(vma_flags));
Otherwise, LGTM, feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
[...]
^ permalink raw reply
* Re: [PATCH 07/13] mm/vma: rename vma_get_page_prot to vma_flags_to_page_prot
From: Lance Yang @ 2026-07-02 12:25 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
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: <fc8ac30d03d29d236e76542b36432bba315aca60.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:30PM +0100, 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.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
straight rename, no stale callers that I can spot ;) Feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
^ permalink raw reply
* Re: [PATCH 08/13] mm: introduce vma_get_page_prot() and use it
From: Lance Yang @ 2026-07-02 12:38 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
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: <3bb8bdc4788230c33102166d56cbc5abfad9d4cb.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:31PM +0100, 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.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
> drivers/gpu/drm/drm_gem.c | 2 +-
> drivers/gpu/drm/drm_gem_dma_helper.c | 2 +-
> drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 6 +++---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 12 ++++++------
> drivers/gpu/drm/msm/msm_gem.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_gem.c | 6 +++---
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 2 +-
> drivers/gpu/drm/tegra/gem.c | 2 +-
> drivers/gpu/drm/virtio/virtgpu_vram.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 2 +-
> drivers/gpu/drm/xe/xe_device.c | 2 +-
> drivers/gpu/drm/xe/xe_mmio_gem.c | 2 +-
> drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +-
> drivers/video/fbdev/core/fb_io_fops.c | 2 +-
One missed?
drivers/gpu/drm/panthor/panthor_gem.c still has:
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
Can use vma_get_page_prot(vma) too.
[...]
^ permalink raw reply
* Re: [PATCH 09/13] mm/vma: update create_init_stack_vma() to use vma_flags_t
From: Lance Yang @ 2026-07-02 12:50 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
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: <34689784ee6856f100c02ad4eabeaa4db643713a.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:32PM +0100, 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.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
Nothing looks off to me ;) Feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
^ permalink raw reply
* Re: [PATCH 10/13] mm/vma: convert miscellaneous uses of VMA flags in core mm
From: Lance Yang @ 2026-07-02 13:12 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
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: <1e7d834c887b6a65627d730addcff13d458c6268.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:33PM +0100, 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.
>
>Also update __install_special_mapping() to rearrange things slightly to
>accommodate the changes.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
[...]
>diff --git a/mm/vma.c b/mm/vma.c
>index b81c05e67a61..ab2ef0f04420 100644
>--- a/mm/vma.c
>+++ b/mm/vma.c
>@@ -3417,23 +3417,27 @@ struct vm_area_struct *__install_special_mapping(
> vm_flags_t vm_flags, void *priv,
> const struct vm_operations_struct *ops)
> {
>- int ret;
>+ vma_flags_t vma_flags = legacy_to_vma_flags(vm_flags);
> struct vm_area_struct *vma;
>+ int ret;
>
> vma = vm_area_alloc(mm);
>- if (unlikely(vma == NULL))
>+ if (unlikely(!vma))
> return ERR_PTR(-ENOMEM);
>
>- vma_set_range(vma, addr, addr + len, 0);
>- vm_flags |= vma_flags_to_legacy(mm->def_vma_flags) | VM_DONTEXPAND;
>+ vma_flags_set_mask(&vma_flags, mm->def_vma_flags);
>+ vma_flags_set(&vma_flags, VMA_DONTEXPAND_BIT);
> if (pgtable_supports_soft_dirty())
>- vm_flags |= VM_SOFTDIRTY;
>- vm_flags_init(vma, vm_flags & ~VM_LOCKED_MASK);
>+ vma_flags_set(&vma_flags, VMA_SOFTDIRTY_BIT);
>+ vma_flags_clear_mask(&vma_flags, VMA_LOCKED_MASK);
>+ vma->flags = vma_flags;
Maybe worth a vma_flags_init() helper here to mirror vm_flags_init()?
With this open-coded, we lose the soft-dirty WARN_ON_ONCE sanity check.
Might be nicer to keep that check in one place ;)
[...]
^ 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