* [PATCH 0/9] drm: Limit DRM_IOCTL_WAIT_VBLANK to vblank interrupts
From: Thomas Zimmermann @ 2026-05-15 11:55 UTC (permalink / raw)
To: simona, airlied, mdaenzer, pekka.paalanen, jadahl, contact,
maarten.lankhorst, mripard
Cc: amd-gfx, dri-devel, linux-hyperv, virtualization, spice-devel,
Thomas Zimmermann
DRM's WAIT_VBLANK ioctl synchronizes user-space clients to display
refresh. This is meaningless with vblank timers, which run unrelated
to the hardware's vblank.
Disable the ioctl for simulated vblanks. Set DRM_VBLANK_FLAG_SIMULATED
for CRTCs with simulated vblank events in all such drivers. The vblank
timers of these devices still rate-limit the number of page-flip events
to match the display refresh.
According to maintainers, user-space compositors do not require the ioctl
for rate-limitting display output. Weston and Kwin rely on page-flip
events. Mutter uses and internal timer to limit the number of display
updates per second.
When testing with mutter and weston, the page-flip rate appears correct
with the patch set applied.
This change has been discussed at length on IRC recently.
https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2026-05-08&show_html=true
https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2026-05-12&show_html=true
https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2026-05-13&show_html=true
Thomas Zimmermann (9):
drm/vblank: Add drmm_vblank_init() to indicate managed cleanup
drm/vblank: Add DRM_VBLANK_FLAG_SIMULATED
drm/amdgpu: vkms: Set DRM_VBLANK_FLAG_SIMULATED
drm/bochs: Set DRM_VBLANK_FLAG_SIMULATED
drm/cirrus: Set DRM_VBLANK_FLAG_SIMULATED
drm/hypervdrm: Set DRM_VBLANK_FLAG_SIMULATED
drm/qxl: Set DRM_VBLANK_FLAG_SIMULATED
drm/virtgpu: Set DRM_VBLANK_FLAG_SIMULATED
drm/vkms: Set DRM_VBLANK_FLAG_SIMULATED
drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 3 ++-
drivers/gpu/drm/drm_vblank.c | 19 ++++++++++++-------
drivers/gpu/drm/drm_vblank_helper.c | 2 +-
drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 2 +-
drivers/gpu/drm/qxl/qxl_display.c | 2 +-
drivers/gpu/drm/tiny/bochs.c | 2 +-
drivers/gpu/drm/tiny/cirrus-qemu.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_display.c | 2 +-
drivers/gpu/drm/vkms/vkms_drv.c | 4 ++--
include/drm/drm_crtc.h | 2 +-
include/drm/drm_device.h | 2 +-
include/drm/drm_vblank.h | 15 ++++++++++++++-
12 files changed, 38 insertions(+), 19 deletions(-)
base-commit: 121c16f9d8c56ea07263df84ab971cc10870fe88
--
2.54.0
^ permalink raw reply
* [PATCH 1/9] drm/vblank: Add drmm_vblank_init() to indicate managed cleanup
From: Thomas Zimmermann @ 2026-05-15 11:55 UTC (permalink / raw)
To: simona, airlied, mdaenzer, pekka.paalanen, jadahl, contact,
maarten.lankhorst, mripard
Cc: amd-gfx, dri-devel, linux-hyperv, virtualization, spice-devel,
Thomas Zimmermann
In-Reply-To: <20260515120916.333614-1-tzimmermann@suse.de>
Rename drm_vblank_init() to drmm_vblank_init(). As the initializer
function sets up managed cleanup, it should use the drmm prefix. Keep
the old name around until all callers have been converted.
Also add a flags argument to the function. The first use of the flags
will be to distinguish between hardware vblank interrupts and simulated
vblank timeouts.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/gpu/drm/drm_vblank.c | 16 +++++++++-------
drivers/gpu/drm/drm_vblank_helper.c | 2 +-
include/drm/drm_crtc.h | 2 +-
include/drm/drm_device.h | 2 +-
include/drm/drm_vblank.h | 10 +++++++++-
5 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index f90fb2d13e42..21ca91b4c014 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -117,7 +117,7 @@
* optionally provide a hardware vertical blanking counter.
*
* Drivers must initialize the vertical blanking handling core with a call to
- * drm_vblank_init(). Minimally, a driver needs to implement
+ * drmm_vblank_init(). Minimally, a driver needs to implement
* &drm_crtc_funcs.enable_vblank and &drm_crtc_funcs.disable_vblank plus call
* drm_crtc_handle_vblank() in its vblank interrupt handler for working vblank
* support.
@@ -146,7 +146,7 @@
* See also DRM vblank helpers for more information.
*
* Drivers without support for vertical-blanking interrupts nor timers must
- * not call drm_vblank_init(). For these drivers, atomic helpers will
+ * not call drmm_vblank_init(). For these drivers, atomic helpers will
* automatically generate fake vblank events as part of the display update.
* This functionality also can be controlled by the driver by enabling and
* disabling struct drm_crtc_state.no_vblank.
@@ -519,7 +519,7 @@ static void vblank_disable_fn(struct timer_list *t)
spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
}
-static void drm_vblank_init_release(struct drm_device *dev, void *ptr)
+static void drmm_vblank_init_release(struct drm_device *dev, void *ptr)
{
struct drm_vblank_crtc *vblank = ptr;
@@ -534,9 +534,10 @@ static void drm_vblank_init_release(struct drm_device *dev, void *ptr)
}
/**
- * drm_vblank_init - initialize vblank support
+ * drmm_vblank_init - initialize vblank support
* @dev: DRM device
* @num_crtcs: number of CRTCs supported by @dev
+ * @flags: flags for vblank handling
*
* This function initializes vblank support for @num_crtcs display pipelines.
* Cleanup is handled automatically through a cleanup function added with
@@ -545,7 +546,7 @@ static void drm_vblank_init_release(struct drm_device *dev, void *ptr)
* Returns:
* Zero on success or a negative error code on failure.
*/
-int drm_vblank_init(struct drm_device *dev, unsigned int num_crtcs)
+int drmm_vblank_init(struct drm_device *dev, unsigned int num_crtcs, unsigned int flags)
{
int ret;
unsigned int i;
@@ -564,11 +565,12 @@ int drm_vblank_init(struct drm_device *dev, unsigned int num_crtcs)
vblank->dev = dev;
vblank->pipe = i;
+ vblank->flags = flags;
init_waitqueue_head(&vblank->queue);
timer_setup(&vblank->disable_timer, vblank_disable_fn, 0);
seqlock_init(&vblank->seqlock);
- ret = drmm_add_action_or_reset(dev, drm_vblank_init_release,
+ ret = drmm_add_action_or_reset(dev, drmm_vblank_init_release,
vblank);
if (ret)
return ret;
@@ -580,7 +582,7 @@ int drm_vblank_init(struct drm_device *dev, unsigned int num_crtcs)
return 0;
}
-EXPORT_SYMBOL(drm_vblank_init);
+EXPORT_SYMBOL(drmm_vblank_init);
/**
* drm_dev_has_vblank - test if vblanking has been initialized for
diff --git a/drivers/gpu/drm/drm_vblank_helper.c b/drivers/gpu/drm/drm_vblank_helper.c
index d3f8147ecdc1..5b05ab72e133 100644
--- a/drivers/gpu/drm/drm_vblank_helper.c
+++ b/drivers/gpu/drm/drm_vblank_helper.c
@@ -25,7 +25,7 @@
* for drivers without further requirements. The initializer macro
* DRM_CRTC_HELPER_VBLANK_FUNCS sets them coveniently.
*
- * Once the driver enables vblank support with drm_vblank_init(), each
+ * Once the driver enables vblank support with drmm_vblank_init(), each
* CRTC's vblank timer fires according to the programmed display mode. By
* default, the vblank timer invokes drm_crtc_handle_vblank(). Drivers with
* more specific requirements can set their own handler function in
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c6dbe8b7db9e..f981468d9a00 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -163,7 +163,7 @@ struct drm_crtc_state {
*
* One usage is for drivers and/or hardware without support for VBLANK
* interrupts. Such drivers typically do not initialize vblanking
- * (i.e., call drm_vblank_init() with the number of CRTCs). For CRTCs
+ * (i.e., call drmm_vblank_init() with the number of CRTCs). For CRTCs
* without initialized vblanking, this field is set to true in
* drm_atomic_helper_check_modeset(), and a fake VBLANK event will be
* send out on each update of the display pipeline by
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index bc78fb77cc27..381417c6b6f5 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -283,7 +283,7 @@ struct drm_device {
* Array of vblank tracking structures, one per &struct drm_crtc. For
* historical reasons (vblank support predates kernel modesetting) this
* is free-standing and not part of &struct drm_crtc itself. It must be
- * initialized explicitly by calling drm_vblank_init().
+ * initialized explicitly by calling drmm_vblank_init().
*/
struct drm_vblank_crtc *vblank;
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index 2fcef9c0f5b1..39a201b83781 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -282,10 +282,12 @@ struct drm_vblank_crtc {
* @vblank_timer: Holds the state of the vblank timer
*/
struct drm_vblank_crtc_timer vblank_timer;
+
+ unsigned int flags;
};
struct drm_vblank_crtc *drm_crtc_vblank_crtc(struct drm_crtc *crtc);
-int drm_vblank_init(struct drm_device *dev, unsigned int num_crtcs);
+int drmm_vblank_init(struct drm_device *dev, unsigned int num_crtcs, unsigned int flags);
bool drm_dev_has_vblank(const struct drm_device *dev);
u64 drm_crtc_vblank_count(struct drm_crtc *crtc);
u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
@@ -321,6 +323,12 @@ int drm_crtc_vblank_start_timer(struct drm_crtc *crtc);
void drm_crtc_vblank_cancel_timer(struct drm_crtc *crtc);
void drm_crtc_vblank_get_vblank_timeout(struct drm_crtc *crtc, ktime_t *vblank_time);
+/* deprecated; use drmm_vblank_init() instead */
+static inline int drm_vblank_init(struct drm_device *dev, unsigned int num_crtcs)
+{
+ return drmm_vblank_init(dev, num_crtcs, 0);
+}
+
/*
* Helpers for struct drm_crtc_funcs
*/
--
2.54.0
^ permalink raw reply related
* [PATCH 2/9] drm/vblank: Add DRM_VBLANK_FLAG_SIMULATED
From: Thomas Zimmermann @ 2026-05-15 11:55 UTC (permalink / raw)
To: simona, airlied, mdaenzer, pekka.paalanen, jadahl, contact,
maarten.lankhorst, mripard
Cc: amd-gfx, dri-devel, linux-hyperv, virtualization, spice-devel,
Thomas Zimmermann
In-Reply-To: <20260515120916.333614-1-tzimmermann@suse.de>
Add DRM_VBLANK_FLAG_SIMULATED for CRTCs that do not have a hardware
vblank interrupt. Setting the flag tells DRM to not report vblank
capabilities from the WAIT_VBLANK ioctl.
DRM_IOCTL_WAIT_VBLANK queries timestamps from a vblank event or waits
for the next vblank event to occur. DRM clients use this functionality
to synchronize their output with the display's vblank phase. Hence this
is only supported for hardware implementations.
Software implementations are not synchronized to the display and merely
act as a rate limiter for page-flip events. The WAIT_VBLANK ioctl thus
should fail with an error.
Suggested-by: Simona Vetter <simona@ffwll.ch>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/gpu/drm/drm_vblank.c | 3 +++
include/drm/drm_vblank.h | 5 +++++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 21ca91b4c014..92b699a4e8be 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1794,6 +1794,9 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, void *data,
vblank = drm_vblank_crtc(dev, pipe);
+ if (vblank->flags & DRM_VBLANK_FLAG_SIMULATED)
+ return -EOPNOTSUPP;
+
/* If the counter is currently enabled and accurate, short-circuit
* queries to return the cached timestamp of the last vblank.
*/
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index 39a201b83781..03fa7259b6ac 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -37,6 +37,11 @@ struct drm_device;
struct drm_crtc;
struct drm_vblank_work;
+/**
+ * DRM_VBLANK_FLAG_SIMULATED - vblank uses a software timer
+ */
+#define DRM_VBLANK_FLAG_SIMULATED BIT(1)
+
/**
* struct drm_pending_vblank_event - pending vblank event tracking
*/
--
2.54.0
^ permalink raw reply related
* [PATCH 3/9] drm/amdgpu: vkms: Set DRM_VBLANK_FLAG_SIMULATED
From: Thomas Zimmermann @ 2026-05-15 11:55 UTC (permalink / raw)
To: simona, airlied, mdaenzer, pekka.paalanen, jadahl, contact,
maarten.lankhorst, mripard
Cc: amd-gfx, dri-devel, linux-hyperv, virtualization, spice-devel,
Thomas Zimmermann
In-Reply-To: <20260515120916.333614-1-tzimmermann@suse.de>
Mark the vblank event on amdgpu's vkms as simulated, so that the
WAIT_VBLANK ioctl fails with an error. The ioctl should not be
supported because the output is not synchronized to a display refresh.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
index 170adaf7e76a..bc88acc819a6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
@@ -413,7 +413,8 @@ static int amdgpu_vkms_sw_init(struct amdgpu_ip_block *ip_block)
return r;
}
- r = drm_vblank_init(adev_to_drm(adev), adev->mode_info.num_crtc);
+ r = drmm_vblank_init(adev_to_drm(adev), adev->mode_info.num_crtc,
+ DRM_VBLANK_FLAG_SIMULATED);
if (r)
return r;
--
2.54.0
^ permalink raw reply related
* [PATCH 4/9] drm/bochs: Set DRM_VBLANK_FLAG_SIMULATED
From: Thomas Zimmermann @ 2026-05-15 11:55 UTC (permalink / raw)
To: simona, airlied, mdaenzer, pekka.paalanen, jadahl, contact,
maarten.lankhorst, mripard
Cc: amd-gfx, dri-devel, linux-hyperv, virtualization, spice-devel,
Thomas Zimmermann
In-Reply-To: <20260515120916.333614-1-tzimmermann@suse.de>
Mark the vblank event on bochs as simulated, so that the WAIT_VBLANK
ioctl fails with an error. The ioctl should not be supported because
the output is not synchronized to a display refresh.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/gpu/drm/tiny/bochs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c
index e2d957e51505..b5955ef39e31 100644
--- a/drivers/gpu/drm/tiny/bochs.c
+++ b/drivers/gpu/drm/tiny/bochs.c
@@ -677,7 +677,7 @@ static int bochs_kms_init(struct bochs_device *bochs)
drm_connector_attach_edid_property(connector);
drm_connector_attach_encoder(connector, encoder);
- ret = drm_vblank_init(dev, 1);
+ ret = drmm_vblank_init(dev, 1, DRM_VBLANK_FLAG_SIMULATED);
if (ret)
return ret;
--
2.54.0
^ permalink raw reply related
* [PATCH 6/9] drm/hypervdrm: Set DRM_VBLANK_FLAG_SIMULATED
From: Thomas Zimmermann @ 2026-05-15 11:55 UTC (permalink / raw)
To: simona, airlied, mdaenzer, pekka.paalanen, jadahl, contact,
maarten.lankhorst, mripard
Cc: amd-gfx, dri-devel, linux-hyperv, virtualization, spice-devel,
Thomas Zimmermann
In-Reply-To: <20260515120916.333614-1-tzimmermann@suse.de>
Mark the vblank event on hypervdrm as simulated, so that the WAIT_VBLANK
ioctl fails with an error. The ioctl should not be supported because the
output is not synchronized to a display refresh.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c b/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
index 1bbb7de5ab49..24bed31c35e7 100644
--- a/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
+++ b/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
@@ -329,7 +329,7 @@ int hyperv_mode_config_init(struct hyperv_drm_device *hv)
return ret;
}
- ret = drm_vblank_init(dev, 1);
+ ret = drmm_vblank_init(dev, 1, DRM_VBLANK_FLAG_SIMULATED);
if (ret)
return ret;
--
2.54.0
^ permalink raw reply related
* [PATCH 5/9] drm/cirrus: Set DRM_VBLANK_FLAG_SIMULATED
From: Thomas Zimmermann @ 2026-05-15 11:55 UTC (permalink / raw)
To: simona, airlied, mdaenzer, pekka.paalanen, jadahl, contact,
maarten.lankhorst, mripard
Cc: amd-gfx, dri-devel, linux-hyperv, virtualization, spice-devel,
Thomas Zimmermann
In-Reply-To: <20260515120916.333614-1-tzimmermann@suse.de>
Mark the vblank event on cirrus as simulated, so that the WAIT_VBLANK
ioctl fails with an error. The ioctl should not be supported because
the output is not synchronized to a display refresh.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/gpu/drm/tiny/cirrus-qemu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/cirrus-qemu.c b/drivers/gpu/drm/tiny/cirrus-qemu.c
index 075221b431d3..01522d1158b2 100644
--- a/drivers/gpu/drm/tiny/cirrus-qemu.c
+++ b/drivers/gpu/drm/tiny/cirrus-qemu.c
@@ -501,7 +501,7 @@ static int cirrus_pipe_init(struct cirrus_device *cirrus)
if (ret)
return ret;
- ret = drm_vblank_init(dev, 1);
+ ret = drmm_vblank_init(dev, 1, DRM_VBLANK_FLAG_SIMULATED);
if (ret)
return ret;
--
2.54.0
^ permalink raw reply related
* [PATCH 9/9] drm/vkms: Set DRM_VBLANK_FLAG_SIMULATED
From: Thomas Zimmermann @ 2026-05-15 11:55 UTC (permalink / raw)
To: simona, airlied, mdaenzer, pekka.paalanen, jadahl, contact,
maarten.lankhorst, mripard
Cc: amd-gfx, dri-devel, linux-hyperv, virtualization, spice-devel,
Thomas Zimmermann
In-Reply-To: <20260515120916.333614-1-tzimmermann@suse.de>
Mark the vblank event on vkms as simulated, so that the WAIT_VBLANK
ioctl fails with an error. The ioctl should not be supported because
the output is not synchronized to a display refresh.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/gpu/drm/vkms/vkms_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 5a640b531d88..c4cfa1e5ab01 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -192,8 +192,8 @@ int vkms_create(struct vkms_config *config)
goto out_devres;
}
- ret = drm_vblank_init(&vkms_device->drm,
- vkms_config_get_num_crtcs(config));
+ ret = drmm_vblank_init(&vkms_device->drm, vkms_config_get_num_crtcs(config),
+ DRM_VBLANK_FLAG_SIMULATED);
if (ret) {
DRM_ERROR("Failed to vblank\n");
goto out_devres;
--
2.54.0
^ permalink raw reply related
* [PATCH 7/9] drm/qxl: Set DRM_VBLANK_FLAG_SIMULATED
From: Thomas Zimmermann @ 2026-05-15 11:55 UTC (permalink / raw)
To: simona, airlied, mdaenzer, pekka.paalanen, jadahl, contact,
maarten.lankhorst, mripard
Cc: amd-gfx, dri-devel, linux-hyperv, virtualization, spice-devel,
Thomas Zimmermann
In-Reply-To: <20260515120916.333614-1-tzimmermann@suse.de>
Mark the vblank event on qxl as simulated, so that the WAIT_VBLANK
ioctl fails with an error. The ioctl should not be supported because
the output is not synchronized to a display refresh.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/gpu/drm/qxl/qxl_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c
index a026bd35ef48..b808fdebbd89 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -1300,7 +1300,7 @@ int qxl_modeset_init(struct qxl_device *qdev)
qxl_display_read_client_monitors_config(qdev);
- ret = drm_vblank_init(&qdev->ddev, qxl_num_crtc);
+ ret = drmm_vblank_init(&qdev->ddev, qxl_num_crtc, DRM_VBLANK_FLAG_SIMULATED);
if (ret)
return ret;
--
2.54.0
^ permalink raw reply related
* [PATCH 8/9] drm/virtgpu: Set DRM_VBLANK_FLAG_SIMULATED
From: Thomas Zimmermann @ 2026-05-15 11:55 UTC (permalink / raw)
To: simona, airlied, mdaenzer, pekka.paalanen, jadahl, contact,
maarten.lankhorst, mripard
Cc: amd-gfx, dri-devel, linux-hyperv, virtualization, spice-devel,
Thomas Zimmermann
In-Reply-To: <20260515120916.333614-1-tzimmermann@suse.de>
Mark the vblank event on virtgpu as simulated, so that the WAIT_VBLANK
ioctl fails with an error. The ioctl should not be supported because
the output is not synchronized to a display refresh.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/gpu/drm/virtio/virtgpu_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c
index 44ffffec550f..558d8001c54f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -381,7 +381,7 @@ int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev)
for (i = 0 ; i < vgdev->num_scanouts; ++i)
vgdev_output_init(vgdev, i);
- ret = drm_vblank_init(vgdev->ddev, vgdev->num_scanouts);
+ ret = drmm_vblank_init(vgdev->ddev, vgdev->num_scanouts, DRM_VBLANK_FLAG_SIMULATED);
if (ret)
return ret;
--
2.54.0
^ permalink raw reply related
* [PATCH RESEND] ALSA: virtio: Add missing 384 kHz PCM rate mapping
From: Cássio Gabriel @ 2026-05-15 13:32 UTC (permalink / raw)
To: Takashi Iwai, Anton Yakovlev, Michael S. Tsirkin, Jaroslav Kysela
Cc: virtualization, linux-sound, linux-kernel, stable,
Cássio Gabriel
The VirtIO sound UAPI defines VIRTIO_SND_PCM_RATE_384000, and ALSA
has SNDRV_PCM_RATE_384000. However, virtio-snd's rate conversion
tables stop at 192 kHz.
A device advertising only 384 kHz is rejected as having no supported
PCM frame rates. A device advertising 384 kHz together with lower rates
does not expose 384 kHz through the ALSA hardware constraints. The
selected ALSA rate also needs a reverse mapping for SET_PARAMS.
Add the missing 384 kHz entries to both conversion tables.
Fixes: 29b96bf50ba9 ("ALSA: virtio: build PCM devices and substream hardware descriptors")
Fixes: da76e9f3e43a ("ALSA: virtio: PCM substream operators")
Cc: stable@vger.kernel.org
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
---
sound/virtio/virtio_pcm.c | 3 ++-
sound/virtio/virtio_pcm_ops.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/sound/virtio/virtio_pcm.c b/sound/virtio/virtio_pcm.c
index eb9cc8131905..be3893de40a5 100644
--- a/sound/virtio/virtio_pcm.c
+++ b/sound/virtio/virtio_pcm.c
@@ -77,7 +77,8 @@ static const struct virtsnd_v2a_rate g_v2a_rate_map[] = {
[VIRTIO_SND_PCM_RATE_88200] = { SNDRV_PCM_RATE_88200, 88200 },
[VIRTIO_SND_PCM_RATE_96000] = { SNDRV_PCM_RATE_96000, 96000 },
[VIRTIO_SND_PCM_RATE_176400] = { SNDRV_PCM_RATE_176400, 176400 },
- [VIRTIO_SND_PCM_RATE_192000] = { SNDRV_PCM_RATE_192000, 192000 }
+ [VIRTIO_SND_PCM_RATE_192000] = { SNDRV_PCM_RATE_192000, 192000 },
+ [VIRTIO_SND_PCM_RATE_384000] = { SNDRV_PCM_RATE_384000, 384000 }
};
/**
diff --git a/sound/virtio/virtio_pcm_ops.c b/sound/virtio/virtio_pcm_ops.c
index 6297a9c61e70..1105e7ff3523 100644
--- a/sound/virtio/virtio_pcm_ops.c
+++ b/sound/virtio/virtio_pcm_ops.c
@@ -90,7 +90,8 @@ static const struct virtsnd_a2v_rate g_a2v_rate_map[] = {
{ 88200, VIRTIO_SND_PCM_RATE_88200 },
{ 96000, VIRTIO_SND_PCM_RATE_96000 },
{ 176400, VIRTIO_SND_PCM_RATE_176400 },
- { 192000, VIRTIO_SND_PCM_RATE_192000 }
+ { 192000, VIRTIO_SND_PCM_RATE_192000 },
+ { 384000, VIRTIO_SND_PCM_RATE_384000 }
};
static int virtsnd_pcm_sync_stop(struct snd_pcm_substream *substream);
---
base-commit: fac9a31701803e4e41fdb7b5c71582c65cf47176
change-id: 20260422-alsa-virtio-384k-rate-723fe9772fa6
Best regards,
--
Cássio Gabriel <cassiogabrielcontato@gmail.com>
--
Cássio Gabriel <cassiogabrielcontato@gmail.com>
^ permalink raw reply related
* [PATCH] vsock/virtio: fix potential unbounded skb queue
From: Luigi Leonardi @ 2026-05-15 14:22 UTC (permalink / raw)
To: stable
Cc: Luigi Leonardi, Stefano Garzarella, Eric Dumazet, Arseniy Krasnov,
Stefan Hajnoczi, Michael S. Tsirkin, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, Jakub Kicinski
From: Eric Dumazet <edumazet@google.com>
Upstream commit 059b7dbd20a6f0c539a45ddff1573cb8946685b5
virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.
virtio_transport_recv_enqueue() skips coalescing for packets
with VIRTIO_VSOCK_SEQ_EOM.
If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,
a very large number of packets can be queued
because vvs->rx_bytes stays at 0.
Fix this by estimating the skb metadata size:
(Number of skbs in the queue) * SKB_TRUESIZE(0)
Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Stefano Garzarella <sgarzare@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: Eugenio Pérez <eperezma@redhat.com>
Cc: virtualization@lists.linux.dev
Link: https://patch.msgid.link/20260430122653.554058-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[LL: Fixed conflict since this tree does not use buf_used added by commit
45ca7e9f0730 ("vsock/virtio: fix `rx_bytes` accounting for stream sockets")]
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
---
net/vmw_vsock/virtio_transport_common.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index 4c374c36c29d..86e3051d000e 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -283,7 +283,9 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
u32 len)
{
- if (vvs->rx_bytes + len > vvs->buf_alloc)
+ u64 skb_overhead = (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0);
+
+ if (skb_overhead + vvs->rx_bytes + len > vvs->buf_alloc)
return false;
vvs->rx_bytes += len;
---
base-commit: 3b9f64db049687c0d38b4b3ef2f297f0642179af
change-id: 20260515-dumazet-07c0c855a9e2
Best regards,
--
Luigi Leonardi <leonardi@redhat.com>
^ permalink raw reply related
* Re: [PATCH] vsock/virtio: fix potential unbounded skb queue
From: Luigi Leonardi @ 2026-05-15 14:23 UTC (permalink / raw)
To: stable
Cc: Stefano Garzarella, Eric Dumazet, Arseniy Krasnov,
Stefan Hajnoczi, Michael S. Tsirkin, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, Jakub Kicinski
In-Reply-To: <20260515-dumazet-v1-1-73468c902889@redhat.com>
On Fri, May 15, 2026 at 04:22:12PM +0200, Luigi Leonardi wrote:
>From: Eric Dumazet <edumazet@google.com>
>
>Upstream commit 059b7dbd20a6f0c539a45ddff1573cb8946685b5
>
>virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.
>
>virtio_transport_recv_enqueue() skips coalescing for packets
>with VIRTIO_VSOCK_SEQ_EOM.
>
>If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,
>a very large number of packets can be queued
>because vvs->rx_bytes stays at 0.
>
>Fix this by estimating the skb metadata size:
>
> (Number of skbs in the queue) * SKB_TRUESIZE(0)
>
>Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
>Signed-off-by: Eric Dumazet <edumazet@google.com>
>Cc: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
>Cc: Stefan Hajnoczi <stefanha@redhat.com>
>Cc: Stefano Garzarella <sgarzare@redhat.com>
>Cc: Michael S. Tsirkin <mst@redhat.com>
>Cc: Jason Wang <jasowang@redhat.com>
>Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
>Cc: Eugenio Pérez <eperezma@redhat.com>
>Cc: virtualization@lists.linux.dev
>Link: https://patch.msgid.link/20260430122653.554058-1-edumazet@google.com
>Signed-off-by: Jakub Kicinski <kuba@kernel.org>
>[LL: Fixed conflict since this tree does not use buf_used added by commit
> 45ca7e9f0730 ("vsock/virtio: fix `rx_bytes` accounting for stream sockets")]
>Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
>---
> net/vmw_vsock/virtio_transport_common.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
>index 4c374c36c29d..86e3051d000e 100644
>--- a/net/vmw_vsock/virtio_transport_common.c
>+++ b/net/vmw_vsock/virtio_transport_common.c
>@@ -283,7 +283,9 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
> static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
> u32 len)
> {
>- if (vvs->rx_bytes + len > vvs->buf_alloc)
>+ u64 skb_overhead = (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0);
>+
>+ if (skb_overhead + vvs->rx_bytes + len > vvs->buf_alloc)
> return false;
>
> vvs->rx_bytes += len;
>
>---
>base-commit: 3b9f64db049687c0d38b4b3ef2f297f0642179af
>change-id: 20260515-dumazet-07c0c855a9e2
>
>Best regards,
>--
>Luigi Leonardi <leonardi@redhat.com>
>
Forgot to add this is material for 6.6.y stable tree.
Luigi
^ permalink raw reply
* Re: [PATCH v6 5/7] locking: Add contended_release tracepoint to qspinlock
From: Dmitry Ilvokhin @ 2026-05-15 14:40 UTC (permalink / raw)
To: Steven Rostedt
Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long,
Thomas Bogendoerfer, Juergen Gross, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Thomas Gleixner,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Arnd Bergmann,
Dennis Zhou, Tejun Heo, Christoph Lameter, Masami Hiramatsu,
Mathieu Desnoyers, linux-kernel, linux-mips, virtualization,
linux-arch, linux-mm, linux-trace-kernel, kernel-team,
Paul E. McKenney
In-Reply-To: <20260514120348.7a64facc@gandalf.local.home>
On Thu, May 14, 2026 at 12:03:48PM -0400, Steven Rostedt wrote:
> On Thu, 14 May 2026 14:13:35 +0000
> Dmitry Ilvokhin <d@ilvokhin.com> wrote:
>
> > > > +void __lockfunc queued_spin_release_traced(struct qspinlock *lock)
> > > > +{
> > > > + if (queued_spin_is_contended(lock))
> > > > + trace_call__contended_release(lock);
> > > > + queued_spin_release(lock);
> > >
> > > And then remove the duplicate call of "queued_spin_release()" here.
> >
> > This is the scenario the comment above the static branch describes.
> > Here's what it looks like in practice on x86_64 (defconfig, compiled
> > with GCC 11).
> >
> > Current design (trace + unlock combined, with return):
> >
> > endbr64
> > xchg %ax,%ax ; NOP (static branch)
> > movb $0x0,(%rdi) ; unlock
> > decl %gs:__preempt_count
> > je preempt
> > jmp __x86_return_thunk
> > call queued_spin_release_traced ; cold
> > jmp preempt_handling ; cold
> > call __SCT__preempt_schedule
> > jmp __x86_return_thunk
> >
> > With the trace-only function (no return, unlock after the call):
> >
> > endbr64
> > push %rbx ; saves callee-saved rbx (!)
> > mov %rdi,%rbx ; preserve lock across call (!)
> > xchg %ax,%ax ; NOP (static branch)
> > movb $0x0,(%rbx) ; unlock
> > decl %gs:__preempt_count
> > je preempt
> > pop %rbx ; callee-saved restore (!)
> > jmp __x86_return_thunk
> > call queued_spin_release_traced ; cold
> > jmp unlock ; cold
> > call __SCT__preempt_schedule
> > pop %rbx
> > jmp __x86_return_thunk
> >
> > Three extra instructions marked by "!" on the hot path (push, mov, pop),
> > all wasted when the tracepoint is off. That's the main reason for
> > combining trace and unlock in the same out-of-line function.
>
> Ah, because the return makes it into two tail calls.
>
> I still don't like the duplication, perhaps add some more comments about
> needing to update the other location if anything changes here? And perhaps
> comment that this duplicate code helps the assembly.
My idea was that queued_spin_release() serves the same role that the old
queued_spin_unlock() had: a pure lock-release primitive without tracing.
That was the primary motivation for extracting queued_spin_release() in
the first place (it is just one line of code), so the common release
logic between the traced and non-traced paths is shared explicitly
rather than duplicated semantically.
I agree that this could be explained better. I'll add more comments
there to clarify the rationale. Thanks for the suggestion, Steve.
>
> -- Steve
>
^ permalink raw reply
* Re: [PATCH] vsock/virtio: fix potential unbounded skb queue
From: Greg KH @ 2026-05-15 15:10 UTC (permalink / raw)
To: Luigi Leonardi
Cc: stable, Stefano Garzarella, Eric Dumazet, Arseniy Krasnov,
Stefan Hajnoczi, Michael S. Tsirkin, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, Jakub Kicinski
In-Reply-To: <agcsQ4LlG9ZsvBGR@leonardi-redhat>
On Fri, May 15, 2026 at 04:23:53PM +0200, Luigi Leonardi wrote:
> On Fri, May 15, 2026 at 04:22:12PM +0200, Luigi Leonardi wrote:
> > From: Eric Dumazet <edumazet@google.com>
> >
> > Upstream commit 059b7dbd20a6f0c539a45ddff1573cb8946685b5
> >
> > virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.
> >
> > virtio_transport_recv_enqueue() skips coalescing for packets
> > with VIRTIO_VSOCK_SEQ_EOM.
> >
> > If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,
> > a very large number of packets can be queued
> > because vvs->rx_bytes stays at 0.
> >
> > Fix this by estimating the skb metadata size:
> >
> > (Number of skbs in the queue) * SKB_TRUESIZE(0)
> >
> > Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Cc: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
> > Cc: Stefan Hajnoczi <stefanha@redhat.com>
> > Cc: Stefano Garzarella <sgarzare@redhat.com>
> > Cc: Michael S. Tsirkin <mst@redhat.com>
> > Cc: Jason Wang <jasowang@redhat.com>
> > Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > Cc: Eugenio Pérez <eperezma@redhat.com>
> > Cc: virtualization@lists.linux.dev
> > Link: https://patch.msgid.link/20260430122653.554058-1-edumazet@google.com
> > Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> > [LL: Fixed conflict since this tree does not use buf_used added by commit
> > 45ca7e9f0730 ("vsock/virtio: fix `rx_bytes` accounting for stream sockets")]
> > Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
> > ---
> > net/vmw_vsock/virtio_transport_common.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
> > index 4c374c36c29d..86e3051d000e 100644
> > --- a/net/vmw_vsock/virtio_transport_common.c
> > +++ b/net/vmw_vsock/virtio_transport_common.c
> > @@ -283,7 +283,9 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
> > static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
> > u32 len)
> > {
> > - if (vvs->rx_bytes + len > vvs->buf_alloc)
> > + u64 skb_overhead = (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0);
> > +
> > + if (skb_overhead + vvs->rx_bytes + len > vvs->buf_alloc)
> > return false;
> >
> > vvs->rx_bytes += len;
> >
> > ---
> > base-commit: 3b9f64db049687c0d38b4b3ef2f297f0642179af
> > change-id: 20260515-dumazet-07c0c855a9e2
> >
> > Best regards,
> > --
> > Luigi Leonardi <leonardi@redhat.com>
> >
>
> Forgot to add this is material for 6.6.y stable tree.
What about all of the newer stable trees? You can't just apply a patch
to an old branch :(
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] vsock/virtio: fix potential unbounded skb queue
From: Greg KH @ 2026-05-15 15:11 UTC (permalink / raw)
To: Luigi Leonardi
Cc: stable, Stefano Garzarella, Eric Dumazet, Arseniy Krasnov,
Stefan Hajnoczi, Michael S. Tsirkin, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, Jakub Kicinski
In-Reply-To: <2026051519-shale-scallion-aab7@gregkh>
On Fri, May 15, 2026 at 05:10:39PM +0200, Greg KH wrote:
> On Fri, May 15, 2026 at 04:23:53PM +0200, Luigi Leonardi wrote:
> > On Fri, May 15, 2026 at 04:22:12PM +0200, Luigi Leonardi wrote:
> > > From: Eric Dumazet <edumazet@google.com>
> > >
> > > Upstream commit 059b7dbd20a6f0c539a45ddff1573cb8946685b5
> > >
> > > virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.
> > >
> > > virtio_transport_recv_enqueue() skips coalescing for packets
> > > with VIRTIO_VSOCK_SEQ_EOM.
> > >
> > > If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,
> > > a very large number of packets can be queued
> > > because vvs->rx_bytes stays at 0.
> > >
> > > Fix this by estimating the skb metadata size:
> > >
> > > (Number of skbs in the queue) * SKB_TRUESIZE(0)
> > >
> > > Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
> > > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > > Cc: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
> > > Cc: Stefan Hajnoczi <stefanha@redhat.com>
> > > Cc: Stefano Garzarella <sgarzare@redhat.com>
> > > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > Cc: Jason Wang <jasowang@redhat.com>
> > > Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > Cc: Eugenio Pérez <eperezma@redhat.com>
> > > Cc: virtualization@lists.linux.dev
> > > Link: https://patch.msgid.link/20260430122653.554058-1-edumazet@google.com
> > > Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> > > [LL: Fixed conflict since this tree does not use buf_used added by commit
> > > 45ca7e9f0730 ("vsock/virtio: fix `rx_bytes` accounting for stream sockets")]
> > > Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
> > > ---
> > > net/vmw_vsock/virtio_transport_common.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
> > > index 4c374c36c29d..86e3051d000e 100644
> > > --- a/net/vmw_vsock/virtio_transport_common.c
> > > +++ b/net/vmw_vsock/virtio_transport_common.c
> > > @@ -283,7 +283,9 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
> > > static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
> > > u32 len)
> > > {
> > > - if (vvs->rx_bytes + len > vvs->buf_alloc)
> > > + u64 skb_overhead = (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0);
> > > +
> > > + if (skb_overhead + vvs->rx_bytes + len > vvs->buf_alloc)
> > > return false;
> > >
> > > vvs->rx_bytes += len;
> > >
> > > ---
> > > base-commit: 3b9f64db049687c0d38b4b3ef2f297f0642179af
> > > change-id: 20260515-dumazet-07c0c855a9e2
> > >
> > > Best regards,
> > > --
> > > Luigi Leonardi <leonardi@redhat.com>
> > >
> >
> > Forgot to add this is material for 6.6.y stable tree.
>
> What about all of the newer stable trees? You can't just apply a patch
> to an old branch :(
Ah, is this due to your other email? that makes more sense, sorry for
the noise.
greg "drowning in email" k-h
^ permalink raw reply
* Re: [PATCH 0/9] drm: Limit DRM_IOCTL_WAIT_VBLANK to vblank interrupts
From: Michel Dänzer @ 2026-05-15 15:12 UTC (permalink / raw)
To: Thomas Zimmermann, simona, airlied, pekka.paalanen, jadahl,
contact, maarten.lankhorst, mripard
Cc: amd-gfx, dri-devel, linux-hyperv, virtualization, spice-devel
In-Reply-To: <20260515120916.333614-1-tzimmermann@suse.de>
On 5/15/26 13:55, Thomas Zimmermann wrote:
> DRM's WAIT_VBLANK ioctl synchronizes user-space clients to display
> refresh. This is meaningless with vblank timers, which run unrelated
> to the hardware's vblank.
>
> Disable the ioctl for simulated vblanks. Set DRM_VBLANK_FLAG_SIMULATED
> for CRTCs with simulated vblank events in all such drivers. The vblank
> timers of these devices still rate-limit the number of page-flip events
> to match the display refresh.
>
> According to maintainers, user-space compositors do not require the ioctl
> for rate-limitting display output. Weston and Kwin rely on page-flip
> events. Mutter uses and internal timer to limit the number of display
> updates per second.
Actually mutter fundamentally relies on atomic commit completion events for that, same as Weston & KWin. Mutter uses the WAIT_VBLANK ioctl only for minimizing input → output latency (which can hide issues when completion of atomic commits isn't properly throttled).
(Just a side not on the cover letter, no objections to the patches themselves)
--
Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer
https://redhat.com \ Libre software enthusiast
^ permalink raw reply
* Patch "vsock/virtio: fix potential unbounded skb queue" has been added to the 6.12-stable tree
From: gregkh @ 2026-05-15 15:15 UTC (permalink / raw)
To: AVKrasnov, edumazet, eperezma, gregkh, jasowang, kuba, leonardi,
mst, sgarzare, stefanha, virtualization, xuanzhuo
Cc: stable-commits
This is a note to let you know that I've just added the patch titled
vsock/virtio: fix potential unbounded skb queue
to the 6.12-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
vsock-virtio-fix-potential-unbounded-skb-queue.patch
and it can be found in the queue-6.12 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From 059b7dbd20a6f0c539a45ddff1573cb8946685b5 Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet@google.com>
Date: Thu, 30 Apr 2026 12:26:52 +0000
Subject: vsock/virtio: fix potential unbounded skb queue
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Eric Dumazet <edumazet@google.com>
commit 059b7dbd20a6f0c539a45ddff1573cb8946685b5 upstream.
virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.
virtio_transport_recv_enqueue() skips coalescing for packets
with VIRTIO_VSOCK_SEQ_EOM.
If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,
a very large number of packets can be queued
because vvs->rx_bytes stays at 0.
Fix this by estimating the skb metadata size:
(Number of skbs in the queue) * SKB_TRUESIZE(0)
Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Stefano Garzarella <sgarzare@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: "Eugenio Pérez" <eperezma@redhat.com>
Cc: virtualization@lists.linux.dev
Link: https://patch.msgid.link/20260430122653.554058-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Cc: Luigi Leonardi <leonardi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/vmw_vsock/virtio_transport_common.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -430,7 +430,9 @@ static int virtio_transport_send_pkt_inf
static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
u32 len)
{
- if (vvs->buf_used + len > vvs->buf_alloc)
+ u64 skb_overhead = (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0);
+
+ if (skb_overhead + vvs->buf_used + len > vvs->buf_alloc)
return false;
vvs->rx_bytes += len;
Patches currently in stable-queue which might be from edumazet@google.com are
queue-6.12/vsock-virtio-fix-potential-unbounded-skb-queue.patch
^ permalink raw reply
* Patch "vsock/virtio: fix potential unbounded skb queue" has been added to the 6.18-stable tree
From: gregkh @ 2026-05-15 15:15 UTC (permalink / raw)
To: AVKrasnov, edumazet, eperezma, gregkh, jasowang, kuba, leonardi,
mst, sgarzare, stefanha, virtualization, xuanzhuo
Cc: stable-commits
This is a note to let you know that I've just added the patch titled
vsock/virtio: fix potential unbounded skb queue
to the 6.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
vsock-virtio-fix-potential-unbounded-skb-queue.patch
and it can be found in the queue-6.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From 059b7dbd20a6f0c539a45ddff1573cb8946685b5 Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet@google.com>
Date: Thu, 30 Apr 2026 12:26:52 +0000
Subject: vsock/virtio: fix potential unbounded skb queue
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Eric Dumazet <edumazet@google.com>
commit 059b7dbd20a6f0c539a45ddff1573cb8946685b5 upstream.
virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.
virtio_transport_recv_enqueue() skips coalescing for packets
with VIRTIO_VSOCK_SEQ_EOM.
If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,
a very large number of packets can be queued
because vvs->rx_bytes stays at 0.
Fix this by estimating the skb metadata size:
(Number of skbs in the queue) * SKB_TRUESIZE(0)
Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Stefano Garzarella <sgarzare@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: "Eugenio Pérez" <eperezma@redhat.com>
Cc: virtualization@lists.linux.dev
Link: https://patch.msgid.link/20260430122653.554058-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Cc: Luigi Leonardi <leonardi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/vmw_vsock/virtio_transport_common.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -429,7 +429,9 @@ static int virtio_transport_send_pkt_inf
static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
u32 len)
{
- if (vvs->buf_used + len > vvs->buf_alloc)
+ u64 skb_overhead = (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0);
+
+ if (skb_overhead + vvs->buf_used + len > vvs->buf_alloc)
return false;
vvs->rx_bytes += len;
Patches currently in stable-queue which might be from edumazet@google.com are
queue-6.18/vsock-virtio-fix-potential-unbounded-skb-queue.patch
^ permalink raw reply
* Patch "vsock/virtio: fix potential unbounded skb queue" has been added to the 7.0-stable tree
From: gregkh @ 2026-05-15 15:15 UTC (permalink / raw)
To: AVKrasnov, edumazet, eperezma, gregkh, jasowang, kuba, leonardi,
mst, sgarzare, stefanha, virtualization, xuanzhuo
Cc: stable-commits
This is a note to let you know that I've just added the patch titled
vsock/virtio: fix potential unbounded skb queue
to the 7.0-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
vsock-virtio-fix-potential-unbounded-skb-queue.patch
and it can be found in the queue-7.0 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From 059b7dbd20a6f0c539a45ddff1573cb8946685b5 Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet@google.com>
Date: Thu, 30 Apr 2026 12:26:52 +0000
Subject: vsock/virtio: fix potential unbounded skb queue
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Eric Dumazet <edumazet@google.com>
commit 059b7dbd20a6f0c539a45ddff1573cb8946685b5 upstream.
virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.
virtio_transport_recv_enqueue() skips coalescing for packets
with VIRTIO_VSOCK_SEQ_EOM.
If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,
a very large number of packets can be queued
because vvs->rx_bytes stays at 0.
Fix this by estimating the skb metadata size:
(Number of skbs in the queue) * SKB_TRUESIZE(0)
Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Stefano Garzarella <sgarzare@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: "Eugenio Pérez" <eperezma@redhat.com>
Cc: virtualization@lists.linux.dev
Link: https://patch.msgid.link/20260430122653.554058-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Cc: Luigi Leonardi <leonardi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/vmw_vsock/virtio_transport_common.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -429,7 +429,9 @@ static int virtio_transport_send_pkt_inf
static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
u32 len)
{
- if (vvs->buf_used + len > vvs->buf_alloc)
+ u64 skb_overhead = (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0);
+
+ if (skb_overhead + vvs->buf_used + len > vvs->buf_alloc)
return false;
vvs->rx_bytes += len;
Patches currently in stable-queue which might be from edumazet@google.com are
queue-7.0/vsock-virtio-fix-potential-unbounded-skb-queue.patch
^ permalink raw reply
* Patch "vsock/virtio: fix potential unbounded skb queue" has been added to the 6.6-stable tree
From: gregkh @ 2026-05-15 15:21 UTC (permalink / raw)
To: AVKrasnov, edumazet, eperezma, gregkh, jasowang, kuba, leonardi,
mst, sgarzare, stefanha, virtualization, xuanzhuo
Cc: stable-commits
This is a note to let you know that I've just added the patch titled
vsock/virtio: fix potential unbounded skb queue
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
vsock-virtio-fix-potential-unbounded-skb-queue.patch
and it can be found in the queue-6.6 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From 059b7dbd20a6f0c539a45ddff1573cb8946685b5 Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet@google.com>
Date: Thu, 30 Apr 2026 12:26:52 +0000
Subject: vsock/virtio: fix potential unbounded skb queue
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Eric Dumazet <edumazet@google.com>
commit 059b7dbd20a6f0c539a45ddff1573cb8946685b5 upstream.
virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.
virtio_transport_recv_enqueue() skips coalescing for packets
with VIRTIO_VSOCK_SEQ_EOM.
If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,
a very large number of packets can be queued
because vvs->rx_bytes stays at 0.
Fix this by estimating the skb metadata size:
(Number of skbs in the queue) * SKB_TRUESIZE(0)
Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Stefano Garzarella <sgarzare@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: "Eugenio Pérez" <eperezma@redhat.com>
Cc: virtualization@lists.linux.dev
Link: https://patch.msgid.link/20260430122653.554058-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[LL: Fixed conflict since this tree does not use buf_used added by commit
45ca7e9f0730 ("vsock/virtio: fix `rx_bytes` accounting for stream sockets")]
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/vmw_vsock/virtio_transport_common.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -283,7 +283,9 @@ static int virtio_transport_send_pkt_inf
static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
u32 len)
{
- if (vvs->rx_bytes + len > vvs->buf_alloc)
+ u64 skb_overhead = (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0);
+
+ if (skb_overhead + vvs->rx_bytes + len > vvs->buf_alloc)
return false;
vvs->rx_bytes += len;
Patches currently in stable-queue which might be from edumazet@google.com are
queue-6.6/net-fix-icmp-host-relookup-triggering-ip_rt_bug.patch
queue-6.6/tcp-call-sk_data_ready-after-listener-migration.patch
queue-6.6/net-sched-sch_red-replace-direct-dequeue-call-with-peek-and-qdisc_dequeue_peeked.patch
queue-6.6/ip6_gre-use-cached-t-net-in-ip6erspan_changelink.patch
queue-6.6/vsock-virtio-fix-potential-unbounded-skb-queue.patch
^ permalink raw reply
* Re: [PATCH] vsock/virtio: fix potential unbounded skb queue
From: Michael S. Tsirkin @ 2026-05-15 15:31 UTC (permalink / raw)
To: Luigi Leonardi
Cc: stable, Stefano Garzarella, Eric Dumazet, Arseniy Krasnov,
Stefan Hajnoczi, Jason Wang, Xuan Zhuo, Eugenio Pérez,
virtualization, Jakub Kicinski
In-Reply-To: <20260515-dumazet-v1-1-73468c902889@redhat.com>
On Fri, May 15, 2026 at 04:22:12PM +0200, Luigi Leonardi wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Upstream commit 059b7dbd20a6f0c539a45ddff1573cb8946685b5
>
> virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.
>
> virtio_transport_recv_enqueue() skips coalescing for packets
> with VIRTIO_VSOCK_SEQ_EOM.
>
> If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,
> a very large number of packets can be queued
> because vvs->rx_bytes stays at 0.
>
> Fix this by estimating the skb metadata size:
>
> (Number of skbs in the queue) * SKB_TRUESIZE(0)
>
> Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: Stefano Garzarella <sgarzare@redhat.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Cc: Eugenio Pérez <eperezma@redhat.com>
> Cc: virtualization@lists.linux.dev
> Link: https://patch.msgid.link/20260430122653.554058-1-edumazet@google.com
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> [LL: Fixed conflict since this tree does not use buf_used added by commit
> 45ca7e9f0730 ("vsock/virtio: fix `rx_bytes` accounting for stream sockets")]
> Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
> ---
> net/vmw_vsock/virtio_transport_common.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
> index 4c374c36c29d..86e3051d000e 100644
> --- a/net/vmw_vsock/virtio_transport_common.c
> +++ b/net/vmw_vsock/virtio_transport_common.c
> @@ -283,7 +283,9 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
> static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
> u32 len)
> {
> - if (vvs->rx_bytes + len > vvs->buf_alloc)
> + u64 skb_overhead = (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0);
> +
> + if (skb_overhead + vvs->rx_bytes + len > vvs->buf_alloc)
> return false;
>
> vvs->rx_bytes += len;
>
> ---
> base-commit: 3b9f64db049687c0d38b4b3ef2f297f0642179af
> change-id: 20260515-dumazet-07c0c855a9e2
>
> Best regards,
> --
> Luigi Leonardi <leonardi@redhat.com>
I am not sure we should queue this for stable yet. It causes regressions
that we are now trying to fix.
--
MST
^ permalink raw reply
* Re: Patch "vsock/virtio: fix potential unbounded skb queue" has been added to the 6.6-stable tree
From: Michael S. Tsirkin @ 2026-05-15 15:36 UTC (permalink / raw)
To: gregkh
Cc: AVKrasnov, edumazet, eperezma, jasowang, kuba, leonardi, sgarzare,
stefanha, virtualization, xuanzhuo, stable-commits, stable
In-Reply-To: <2026051553-santa-unretired-a417@gregkh>
On Fri, May 15, 2026 at 05:21:53PM +0200, gregkh@linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> vsock/virtio: fix potential unbounded skb queue
>
> to the 6.6-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>
> The filename of the patch is:
> vsock-virtio-fix-potential-unbounded-skb-queue.patch
> and it can be found in the queue-6.6 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable@vger.kernel.org> know about it.
>
Yea I have some doubts. It fixes the DoS at the cost of losing
messages. We are trying to fix that upstream now, maybe wait
for that?
> >From 059b7dbd20a6f0c539a45ddff1573cb8946685b5 Mon Sep 17 00:00:00 2001
> From: Eric Dumazet <edumazet@google.com>
> Date: Thu, 30 Apr 2026 12:26:52 +0000
> Subject: vsock/virtio: fix potential unbounded skb queue
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> From: Eric Dumazet <edumazet@google.com>
>
> commit 059b7dbd20a6f0c539a45ddff1573cb8946685b5 upstream.
>
> virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.
>
> virtio_transport_recv_enqueue() skips coalescing for packets
> with VIRTIO_VSOCK_SEQ_EOM.
>
> If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,
> a very large number of packets can be queued
> because vvs->rx_bytes stays at 0.
>
> Fix this by estimating the skb metadata size:
>
> (Number of skbs in the queue) * SKB_TRUESIZE(0)
>
> Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: Stefano Garzarella <sgarzare@redhat.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Cc: "Eugenio Pérez" <eperezma@redhat.com>
> Cc: virtualization@lists.linux.dev
> Link: https://patch.msgid.link/20260430122653.554058-1-edumazet@google.com
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> [LL: Fixed conflict since this tree does not use buf_used added by commit
> 45ca7e9f0730 ("vsock/virtio: fix `rx_bytes` accounting for stream sockets")]
> Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> net/vmw_vsock/virtio_transport_common.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> --- a/net/vmw_vsock/virtio_transport_common.c
> +++ b/net/vmw_vsock/virtio_transport_common.c
> @@ -283,7 +283,9 @@ static int virtio_transport_send_pkt_inf
> static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
> u32 len)
> {
> - if (vvs->rx_bytes + len > vvs->buf_alloc)
> + u64 skb_overhead = (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0);
> +
> + if (skb_overhead + vvs->rx_bytes + len > vvs->buf_alloc)
> return false;
>
> vvs->rx_bytes += len;
>
>
> Patches currently in stable-queue which might be from edumazet@google.com are
>
> queue-6.6/net-fix-icmp-host-relookup-triggering-ip_rt_bug.patch
> queue-6.6/tcp-call-sk_data_ready-after-listener-migration.patch
> queue-6.6/net-sched-sch_red-replace-direct-dequeue-call-with-peek-and-qdisc_dequeue_peeked.patch
> queue-6.6/ip6_gre-use-cached-t-net-in-ip6erspan_changelink.patch
> queue-6.6/vsock-virtio-fix-potential-unbounded-skb-queue.patch
^ permalink raw reply
* Re: [PATCH v7 09/31] mm: use folio_zero_user for user pages in post_alloc_hook
From: Gregory Price @ 2026-05-15 15:39 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, David Hildenbrand (Arm), Jason Wang, Xuan Zhuo,
Eugenio Pérez, Muchun Song, Oscar Salvador, Andrew Morton,
Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Brendan Jackman,
Johannes Weiner, Zi Yan, Baolin Wang, Nico Pache, Ryan Roberts,
Dev Jain, Barry Song, Lance Yang, Hugh Dickins, Matthew Brost,
Joshua Hahn, Rakie Kim, Byungchul Park, Ying Huang,
Alistair Popple, Christoph Lameter, David Rientjes,
Roman Gushchin, Harry Yoo, Axel Rasmussen, Yuanchu Xie, Wei Xu,
Chris Li, Kairui Song, Kemeng Shi, Nhat Pham, Baoquan He,
virtualization, linux-mm, Andrea Arcangeli
In-Reply-To: <20260514150750-mutt-send-email-mst@kernel.org>
On Thu, May 14, 2026 at 03:08:13PM -0400, Michael S. Tsirkin wrote:
> On Thu, May 14, 2026 at 02:56:54PM -0400, Gregory Price wrote:
> > On Thu, May 14, 2026 at 02:00:31PM -0400, Michael S. Tsirkin wrote:
> > > On Thu, May 14, 2026 at 09:49:33AM -0400, Gregory Price wrote:
> > >
> > > There are calls with no __GFP_ZERO but they do not allocate userspace pages.
> > >
> > > - drm_pagemap.c: GFP_HIGHUSER -- no zero. But this is a DRM device
> > > page migration, the page content is preserved from the source.
> > >
> > > - test_hmm.c: GFP_HIGHUSER_MOVABLE -- no zero. Test driver, pages get
> > > content from device.
> > >
> > > - mm/ksm.c: GFP_HIGHUSER_MOVABLE -- no zero. KSM merges identical
> > > pages, content comes from the source page (copy).
> > >
> > > - mm/memory.c new_folio = GFP_HIGHUSER_MOVABLE
> > > - no zero. This is CoW, content is copied from old page.
> > >
> > > - mm/userfaultfd.c: GFP_HIGHUSER_MOVABLE - no zero. Content comes from userspace via userfaultfd.
> > >
> > > - arm64/fault.c: __GFP_ZEROTAGS not __GFP_ZERO. MTE tag zeroing, not page zeroing. Page is zeroed separately.
> > >
> >
> > Right, so in all of these cases, it would be just as correct to pass
> > USER_ADDR_NONE I imagine :]
>
> Hmm. Are you sure? Isn't the address used for numa policy?
>
You said "They do not allocate userspace pages" - so wouldn't uaddr be
USER_ADDR_NONE anyway?
Even if they do allocate userspace pages, they weren't passing
__GFP_ZERO before, so either:
1) They did not depend on the buddy to do zeroing before, and
user_addr is just a dead variable in those cases anyway.
or
2) There is a bug, and they should be zeroing the page.
I just see an interesting hardening opportunity.
Not suggesting you actually implement this, to be clear, maybe just
documenting the idea on the thread as a potential follow up.
~Gregory
^ permalink raw reply
* Re: Patch "vsock/virtio: fix potential unbounded skb queue" has been added to the 6.6-stable tree
From: Greg KH @ 2026-05-15 15:41 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: AVKrasnov, edumazet, eperezma, jasowang, kuba, leonardi, sgarzare,
stefanha, virtualization, xuanzhuo, stable-commits, stable
In-Reply-To: <20260515113503-mutt-send-email-mst@kernel.org>
On Fri, May 15, 2026 at 11:36:12AM -0400, Michael S. Tsirkin wrote:
> On Fri, May 15, 2026 at 05:21:53PM +0200, gregkh@linuxfoundation.org wrote:
> >
> > This is a note to let you know that I've just added the patch titled
> >
> > vsock/virtio: fix potential unbounded skb queue
> >
> > to the 6.6-stable tree which can be found at:
> > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> >
> > The filename of the patch is:
> > vsock-virtio-fix-potential-unbounded-skb-queue.patch
> > and it can be found in the queue-6.6 subdirectory.
> >
> > If you, or anyone else, feels it should not be added to the stable tree,
> > please let <stable@vger.kernel.org> know about it.
> >
>
> Yea I have some doubts. It fixes the DoS at the cost of losing
> messages. We are trying to fix that upstream now, maybe wait
> for that?
being bug compatible is good! :(
What's the status of that fix? Should it be reverted elsewhere?
thanks,
greg k-h
^ 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