Re: [PATCH v2] drm/sched: Avoid double re-lock on the job free path
Hi Danilo, On 7/11/25 16:22, Danilo Krummrich wrote: On 7/11/25 9:08 PM, Maíra Canal wrote: Hi Tvrtko, On 11/07/25 12:09, Tvrtko Ursulin wrote: Currently the job free work item will lock sched->job_list_lock first time to see if there are any jobs, free a single job, and then lock again to decide whether to re-queue itself if there are more finished jobs. Since drm_sched_get_finished_job() already looks at the second job in the queue we can simply add the signaled check and have it return the presence of more jobs to be freed to the caller. That way the work item does not have to lock the list again and repeat the signaled check. Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Danilo Krummrich Cc: Matthew Brost Cc: Philipp Stanner --- v2: * Improve commit text and kerneldoc. (Philipp) * Rename run free work helper. (Philipp) Maybe, would it be possible not to rename it? Otherwise, I won't be able to use the function name `drm_sched_run_free_queue()` in the DRM_GPU_SCHED_STAT_NO_HANG series. Not a big deal, but it would ease reintroducing `drm_sched_run_free_queue()` if the series lands after this patch. Do you intend to land your series through a different tree? No, I plan to land my series in drm-misc-next. I'm just waiting our discussion with König to settle down before pushing it. However, if Tvrtko doesn't mind, we can arrange to push this patch after my series. But again, not a big deal, I can rebase it later. Best Regards, - Maíra
Patch "drm/framebuffer: Acquire internal references on GEM handles" has been added to the 6.6-stable tree
This is a note to let you know that I've just added the patch titled
drm/framebuffer: Acquire internal references on GEM handles
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:
drm-framebuffer-acquire-internal-references-on-gem-handles.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 know about it.
>From f6bfc9afc7510cb5e6fbe0a17c507917b0120280 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Mon, 7 Jul 2025 15:11:55 +0200
Subject: drm/framebuffer: Acquire internal references on GEM handles
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Thomas Zimmermann
commit f6bfc9afc7510cb5e6fbe0a17c507917b0120280 upstream.
Acquire GEM handles in drm_framebuffer_init() and release them in
the corresponding drm_framebuffer_cleanup(). Ties the handle's
lifetime to the framebuffer. Not all GEM buffer objects have GEM
handles. If not set, no refcounting takes place. This is the case
for some fbdev emulation. This is not a problem as these GEM objects
do not use dma-bufs and drivers will not release them while fbdev
emulation is running. Framebuffer flags keep a bit per color plane
of which the framebuffer holds a GEM handle reference.
As all drivers use drm_framebuffer_init(), they will now all hold
dma-buf references as fixed in commit 5307dce878d4 ("drm/gem: Acquire
references on GEM handles for framebuffers").
In the GEM framebuffer helpers, restore the original ref counting
on buffer objects. As the helpers for handle refcounting are now
no longer called from outside the DRM core, unexport the symbols.
v3:
- don't mix internal flags with mode flags (Christian)
v2:
- track framebuffer handle refs by flag
- drop gma500 cleanup (Christian)
Signed-off-by: Thomas Zimmermann
Fixes: 5307dce878d4 ("drm/gem: Acquire references on GEM handles for
framebuffers")
Reported-by: Bert Karwatzki
Closes:
https://lore.kernel.org/dri-devel/20250703115915.3096-1-spassw...@web.de/
Tested-by: Bert Karwatzki
Tested-by: Mario Limonciello
Tested-by: Borislav Petkov (AMD)
Cc: Thomas Zimmermann
Cc: Anusha Srivatsa
Cc: Christian König
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc:
Reviewed-by: Christian König
Link: https://lore.kernel.org/r/20250707131224.249496-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_framebuffer.c| 31 --
drivers/gpu/drm/drm_gem.c| 38 +--
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 16 ---
drivers/gpu/drm/drm_internal.h |2 -
include/drm/drm_framebuffer.h|7
5 files changed, 68 insertions(+), 26 deletions(-)
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -844,11 +844,23 @@ void drm_framebuffer_free(struct kref *k
int drm_framebuffer_init(struct drm_device *dev, struct drm_framebuffer *fb,
const struct drm_framebuffer_funcs *funcs)
{
+ unsigned int i;
int ret;
+ bool exists;
if (WARN_ON_ONCE(fb->dev != dev || !fb->format))
return -EINVAL;
+ for (i = 0; i < fb->format->num_planes; i++) {
+ if (drm_WARN_ON_ONCE(dev, fb->internal_flags &
DRM_FRAMEBUFFER_HAS_HANDLE_REF(i)))
+ fb->internal_flags &=
~DRM_FRAMEBUFFER_HAS_HANDLE_REF(i);
+ if (fb->obj[i]) {
+ exists =
drm_gem_object_handle_get_if_exists_unlocked(fb->obj[i]);
+ if (exists)
+ fb->internal_flags |=
DRM_FRAMEBUFFER_HAS_HANDLE_REF(i);
+ }
+ }
+
INIT_LIST_HEAD(&fb->filp_head);
fb->funcs = funcs;
@@ -857,7 +869,7 @@ int drm_framebuffer_init(struct drm_devi
ret = __drm_mode_object_add(dev, &fb->base, DRM_MODE_OBJECT_FB,
false, drm_framebuffer_free);
if (ret)
- goto out;
+ goto err;
mutex_lock(&dev->mode_config.fb_lock);
dev->mode_config.num_fb++;
@@ -865,7 +877,16 @@ int drm_framebuffer_init(struct drm_devi
mutex_unlock(&dev->mode_config.fb_lock);
drm_mode_object_register(dev, &fb->base);
-out:
+
+ return 0;
+
+err:
+ for (i = 0; i < fb->format->num_planes; i++) {
+ if (fb->internal_flags & DRM_FRAMEBUFFER_HAS_HANDLE_REF(i)) {
+ drm_gem_object_handle_put_unlocked(fb->obj[i]);
+ fb->internal_flags &=
~DRM_FRAMEBUFFER_HAS_HANDLE_REF(i);
+ }
+ }
return ret;
}
EXPORT_SYMBOL(drm_frameb
Patch "drm/framebuffer: Acquire internal references on GEM handles" has been added to the 6.15-stable tree
This is a note to let you know that I've just added the patch titled
drm/framebuffer: Acquire internal references on GEM handles
to the 6.15-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:
drm-framebuffer-acquire-internal-references-on-gem-handles.patch
and it can be found in the queue-6.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From f6bfc9afc7510cb5e6fbe0a17c507917b0120280 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Mon, 7 Jul 2025 15:11:55 +0200
Subject: drm/framebuffer: Acquire internal references on GEM handles
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Thomas Zimmermann
commit f6bfc9afc7510cb5e6fbe0a17c507917b0120280 upstream.
Acquire GEM handles in drm_framebuffer_init() and release them in
the corresponding drm_framebuffer_cleanup(). Ties the handle's
lifetime to the framebuffer. Not all GEM buffer objects have GEM
handles. If not set, no refcounting takes place. This is the case
for some fbdev emulation. This is not a problem as these GEM objects
do not use dma-bufs and drivers will not release them while fbdev
emulation is running. Framebuffer flags keep a bit per color plane
of which the framebuffer holds a GEM handle reference.
As all drivers use drm_framebuffer_init(), they will now all hold
dma-buf references as fixed in commit 5307dce878d4 ("drm/gem: Acquire
references on GEM handles for framebuffers").
In the GEM framebuffer helpers, restore the original ref counting
on buffer objects. As the helpers for handle refcounting are now
no longer called from outside the DRM core, unexport the symbols.
v3:
- don't mix internal flags with mode flags (Christian)
v2:
- track framebuffer handle refs by flag
- drop gma500 cleanup (Christian)
Signed-off-by: Thomas Zimmermann
Fixes: 5307dce878d4 ("drm/gem: Acquire references on GEM handles for
framebuffers")
Reported-by: Bert Karwatzki
Closes:
https://lore.kernel.org/dri-devel/20250703115915.3096-1-spassw...@web.de/
Tested-by: Bert Karwatzki
Tested-by: Mario Limonciello
Tested-by: Borislav Petkov (AMD)
Cc: Thomas Zimmermann
Cc: Anusha Srivatsa
Cc: Christian König
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc:
Reviewed-by: Christian König
Link: https://lore.kernel.org/r/20250707131224.249496-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_framebuffer.c| 31 --
drivers/gpu/drm/drm_gem.c| 38 +--
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 16 ---
drivers/gpu/drm/drm_internal.h |2 -
include/drm/drm_framebuffer.h|7
5 files changed, 68 insertions(+), 26 deletions(-)
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -862,11 +862,23 @@ EXPORT_SYMBOL_FOR_TESTS_ONLY(drm_framebu
int drm_framebuffer_init(struct drm_device *dev, struct drm_framebuffer *fb,
const struct drm_framebuffer_funcs *funcs)
{
+ unsigned int i;
int ret;
+ bool exists;
if (WARN_ON_ONCE(fb->dev != dev || !fb->format))
return -EINVAL;
+ for (i = 0; i < fb->format->num_planes; i++) {
+ if (drm_WARN_ON_ONCE(dev, fb->internal_flags &
DRM_FRAMEBUFFER_HAS_HANDLE_REF(i)))
+ fb->internal_flags &=
~DRM_FRAMEBUFFER_HAS_HANDLE_REF(i);
+ if (fb->obj[i]) {
+ exists =
drm_gem_object_handle_get_if_exists_unlocked(fb->obj[i]);
+ if (exists)
+ fb->internal_flags |=
DRM_FRAMEBUFFER_HAS_HANDLE_REF(i);
+ }
+ }
+
INIT_LIST_HEAD(&fb->filp_head);
fb->funcs = funcs;
@@ -875,7 +887,7 @@ int drm_framebuffer_init(struct drm_devi
ret = __drm_mode_object_add(dev, &fb->base, DRM_MODE_OBJECT_FB,
false, drm_framebuffer_free);
if (ret)
- goto out;
+ goto err;
mutex_lock(&dev->mode_config.fb_lock);
dev->mode_config.num_fb++;
@@ -883,7 +895,16 @@ int drm_framebuffer_init(struct drm_devi
mutex_unlock(&dev->mode_config.fb_lock);
drm_mode_object_register(dev, &fb->base);
-out:
+
+ return 0;
+
+err:
+ for (i = 0; i < fb->format->num_planes; i++) {
+ if (fb->internal_flags & DRM_FRAMEBUFFER_HAS_HANDLE_REF(i)) {
+ drm_gem_object_handle_put_unlocked(fb->obj[i]);
+ fb->internal_flags &=
~DRM_FRAMEBUFFER_HAS_HANDLE_REF(i);
+ }
+ }
return ret;
}
EXPORT_SYMBOL(drm_fram
Patch "drm/framebuffer: Acquire internal references on GEM handles" has been added to the 6.12-stable tree
This is a note to let you know that I've just added the patch titled
drm/framebuffer: Acquire internal references on GEM handles
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:
drm-framebuffer-acquire-internal-references-on-gem-handles.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 know about it.
>From f6bfc9afc7510cb5e6fbe0a17c507917b0120280 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Mon, 7 Jul 2025 15:11:55 +0200
Subject: drm/framebuffer: Acquire internal references on GEM handles
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Thomas Zimmermann
commit f6bfc9afc7510cb5e6fbe0a17c507917b0120280 upstream.
Acquire GEM handles in drm_framebuffer_init() and release them in
the corresponding drm_framebuffer_cleanup(). Ties the handle's
lifetime to the framebuffer. Not all GEM buffer objects have GEM
handles. If not set, no refcounting takes place. This is the case
for some fbdev emulation. This is not a problem as these GEM objects
do not use dma-bufs and drivers will not release them while fbdev
emulation is running. Framebuffer flags keep a bit per color plane
of which the framebuffer holds a GEM handle reference.
As all drivers use drm_framebuffer_init(), they will now all hold
dma-buf references as fixed in commit 5307dce878d4 ("drm/gem: Acquire
references on GEM handles for framebuffers").
In the GEM framebuffer helpers, restore the original ref counting
on buffer objects. As the helpers for handle refcounting are now
no longer called from outside the DRM core, unexport the symbols.
v3:
- don't mix internal flags with mode flags (Christian)
v2:
- track framebuffer handle refs by flag
- drop gma500 cleanup (Christian)
Signed-off-by: Thomas Zimmermann
Fixes: 5307dce878d4 ("drm/gem: Acquire references on GEM handles for
framebuffers")
Reported-by: Bert Karwatzki
Closes:
https://lore.kernel.org/dri-devel/20250703115915.3096-1-spassw...@web.de/
Tested-by: Bert Karwatzki
Tested-by: Mario Limonciello
Tested-by: Borislav Petkov (AMD)
Cc: Thomas Zimmermann
Cc: Anusha Srivatsa
Cc: Christian König
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc:
Reviewed-by: Christian König
Link: https://lore.kernel.org/r/20250707131224.249496-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_framebuffer.c| 31 --
drivers/gpu/drm/drm_gem.c| 38 +--
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 16 ---
drivers/gpu/drm/drm_internal.h |2 -
include/drm/drm_framebuffer.h|7
5 files changed, 68 insertions(+), 26 deletions(-)
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -860,11 +860,23 @@ void drm_framebuffer_free(struct kref *k
int drm_framebuffer_init(struct drm_device *dev, struct drm_framebuffer *fb,
const struct drm_framebuffer_funcs *funcs)
{
+ unsigned int i;
int ret;
+ bool exists;
if (WARN_ON_ONCE(fb->dev != dev || !fb->format))
return -EINVAL;
+ for (i = 0; i < fb->format->num_planes; i++) {
+ if (drm_WARN_ON_ONCE(dev, fb->internal_flags &
DRM_FRAMEBUFFER_HAS_HANDLE_REF(i)))
+ fb->internal_flags &=
~DRM_FRAMEBUFFER_HAS_HANDLE_REF(i);
+ if (fb->obj[i]) {
+ exists =
drm_gem_object_handle_get_if_exists_unlocked(fb->obj[i]);
+ if (exists)
+ fb->internal_flags |=
DRM_FRAMEBUFFER_HAS_HANDLE_REF(i);
+ }
+ }
+
INIT_LIST_HEAD(&fb->filp_head);
fb->funcs = funcs;
@@ -873,7 +885,7 @@ int drm_framebuffer_init(struct drm_devi
ret = __drm_mode_object_add(dev, &fb->base, DRM_MODE_OBJECT_FB,
false, drm_framebuffer_free);
if (ret)
- goto out;
+ goto err;
mutex_lock(&dev->mode_config.fb_lock);
dev->mode_config.num_fb++;
@@ -881,7 +893,16 @@ int drm_framebuffer_init(struct drm_devi
mutex_unlock(&dev->mode_config.fb_lock);
drm_mode_object_register(dev, &fb->base);
-out:
+
+ return 0;
+
+err:
+ for (i = 0; i < fb->format->num_planes; i++) {
+ if (fb->internal_flags & DRM_FRAMEBUFFER_HAS_HANDLE_REF(i)) {
+ drm_gem_object_handle_put_unlocked(fb->obj[i]);
+ fb->internal_flags &=
~DRM_FRAMEBUFFER_HAS_HANDLE_REF(i);
+ }
+ }
return ret;
}
EXPORT_SYMBOL(drm_fram
Patch "drm/gem: Acquire references on GEM handles for framebuffers" has been added to the 6.12-stable tree
This is a note to let you know that I've just added the patch titled
drm/gem: Acquire references on GEM handles for framebuffers
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:
drm-gem-acquire-references-on-gem-handles-for-framebuffers.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 know about it.
>From 5307dce878d4126e1b375587318955bd019c3741 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Mon, 30 Jun 2025 10:36:47 +0200
Subject: drm/gem: Acquire references on GEM handles for framebuffers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Thomas Zimmermann
commit 5307dce878d4126e1b375587318955bd019c3741 upstream.
A GEM handle can be released while the GEM buffer object is attached
to a DRM framebuffer. This leads to the release of the dma-buf backing
the buffer object, if any. [1] Trying to use the framebuffer in further
mode-setting operations leads to a segmentation fault. Most easily
happens with driver that use shadow planes for vmap-ing the dma-buf
during a page flip. An example is shown below.
[ 156.791968] [ cut here ]
[ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527
dma_buf_vmap+0x224/0x430
[...]
[ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430
[ 157.043420] Call Trace:
[ 157.045898]
[ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0
[ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0
[ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0
[ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710
[ 157.065567] ? dma_buf_vmap+0x224/0x430
[ 157.069446] ? __warn.cold+0x58/0xe4
[ 157.073061] ? dma_buf_vmap+0x224/0x430
[ 157.077111] ? report_bug+0x1dd/0x390
[ 157.080842] ? handle_bug+0x5e/0xa0
[ 157.084389] ? exc_invalid_op+0x14/0x50
[ 157.088291] ? asm_exc_invalid_op+0x16/0x20
[ 157.092548] ? dma_buf_vmap+0x224/0x430
[ 157.096663] ? dma_resv_get_singleton+0x6d/0x230
[ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10
[ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10
[ 157.110697] drm_gem_shmem_vmap+0x74/0x710
[ 157.114866] drm_gem_vmap+0xa9/0x1b0
[ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0
[ 157.123086] drm_gem_fb_vmap+0xab/0x300
[ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10
[ 157.133032] ? lockdep_init_map_type+0x19d/0x880
[ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0
[ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180
[ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40
[...]
[ 157.346424] ---[ end trace ]---
Acquiring GEM handles for the framebuffer's GEM buffer objects prevents
this from happening. The framebuffer's cleanup later puts the handle
references.
Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object
instance") triggers the segmentation fault easily by using the dma-buf
field more widely. The underlying issue with reference counting has
been present before.
v2:
- acquire the handle instead of the BO (Christian)
- fix comment style (Christian)
- drop the Fixes tag (Christian)
- rename err_ gotos
- add missing Link tag
Suggested-by: Christian König
Signed-off-by: Thomas Zimmermann
Link:
https://elixir.bootlin.com/linux/v6.15/source/drivers/gpu/drm/drm_gem.c#L241 #
[1]
Cc: Thomas Zimmermann
Cc: Anusha Srivatsa
Cc: Christian König
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc:
Reviewed-by: Christian König
Link: https://lore.kernel.org/r/20250630084001.293053-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_gem.c| 44 ---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 16 +
drivers/gpu/drm/drm_internal.h |2 +
3 files changed, 51 insertions(+), 11 deletions(-)
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -186,6 +186,35 @@ void drm_gem_private_object_fini(struct
}
EXPORT_SYMBOL(drm_gem_private_object_fini);
+static void drm_gem_object_handle_get(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+
+ drm_WARN_ON(dev, !mutex_is_locked(&dev->object_name_lock));
+
+ if (obj->handle_count++ == 0)
+ drm_gem_object_get(obj);
+}
+
+/**
+ * drm_gem_object_handle_get_unlocked - acquire reference on user-space handles
+ * @obj: GEM object
+ *
+ * Acquires a reference on the GEM buffer object's handle. Required
+ * to keep the GEM object alive. Call drm_gem_object_handle_put_unlocked()
+ * to release the reference.
+ */
+void drm_gem_object_handle_get_unlocked(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+
+ guard(mutex)(&dev->object
Patch "drm/gem: Acquire references on GEM handles for framebuffers" has been added to the 6.15-stable tree
This is a note to let you know that I've just added the patch titled
drm/gem: Acquire references on GEM handles for framebuffers
to the 6.15-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:
drm-gem-acquire-references-on-gem-handles-for-framebuffers.patch
and it can be found in the queue-6.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 5307dce878d4126e1b375587318955bd019c3741 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Mon, 30 Jun 2025 10:36:47 +0200
Subject: drm/gem: Acquire references on GEM handles for framebuffers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Thomas Zimmermann
commit 5307dce878d4126e1b375587318955bd019c3741 upstream.
A GEM handle can be released while the GEM buffer object is attached
to a DRM framebuffer. This leads to the release of the dma-buf backing
the buffer object, if any. [1] Trying to use the framebuffer in further
mode-setting operations leads to a segmentation fault. Most easily
happens with driver that use shadow planes for vmap-ing the dma-buf
during a page flip. An example is shown below.
[ 156.791968] [ cut here ]
[ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527
dma_buf_vmap+0x224/0x430
[...]
[ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430
[ 157.043420] Call Trace:
[ 157.045898]
[ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0
[ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0
[ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0
[ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710
[ 157.065567] ? dma_buf_vmap+0x224/0x430
[ 157.069446] ? __warn.cold+0x58/0xe4
[ 157.073061] ? dma_buf_vmap+0x224/0x430
[ 157.077111] ? report_bug+0x1dd/0x390
[ 157.080842] ? handle_bug+0x5e/0xa0
[ 157.084389] ? exc_invalid_op+0x14/0x50
[ 157.088291] ? asm_exc_invalid_op+0x16/0x20
[ 157.092548] ? dma_buf_vmap+0x224/0x430
[ 157.096663] ? dma_resv_get_singleton+0x6d/0x230
[ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10
[ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10
[ 157.110697] drm_gem_shmem_vmap+0x74/0x710
[ 157.114866] drm_gem_vmap+0xa9/0x1b0
[ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0
[ 157.123086] drm_gem_fb_vmap+0xab/0x300
[ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10
[ 157.133032] ? lockdep_init_map_type+0x19d/0x880
[ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0
[ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180
[ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40
[...]
[ 157.346424] ---[ end trace ]---
Acquiring GEM handles for the framebuffer's GEM buffer objects prevents
this from happening. The framebuffer's cleanup later puts the handle
references.
Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object
instance") triggers the segmentation fault easily by using the dma-buf
field more widely. The underlying issue with reference counting has
been present before.
v2:
- acquire the handle instead of the BO (Christian)
- fix comment style (Christian)
- drop the Fixes tag (Christian)
- rename err_ gotos
- add missing Link tag
Suggested-by: Christian König
Signed-off-by: Thomas Zimmermann
Link:
https://elixir.bootlin.com/linux/v6.15/source/drivers/gpu/drm/drm_gem.c#L241 #
[1]
Cc: Thomas Zimmermann
Cc: Anusha Srivatsa
Cc: Christian König
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc:
Reviewed-by: Christian König
Link: https://lore.kernel.org/r/20250630084001.293053-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_gem.c| 44 ---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 16 +
drivers/gpu/drm/drm_internal.h |2 +
3 files changed, 51 insertions(+), 11 deletions(-)
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -212,6 +212,35 @@ void drm_gem_private_object_fini(struct
}
EXPORT_SYMBOL(drm_gem_private_object_fini);
+static void drm_gem_object_handle_get(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+
+ drm_WARN_ON(dev, !mutex_is_locked(&dev->object_name_lock));
+
+ if (obj->handle_count++ == 0)
+ drm_gem_object_get(obj);
+}
+
+/**
+ * drm_gem_object_handle_get_unlocked - acquire reference on user-space handles
+ * @obj: GEM object
+ *
+ * Acquires a reference on the GEM buffer object's handle. Required
+ * to keep the GEM object alive. Call drm_gem_object_handle_put_unlocked()
+ * to release the reference.
+ */
+void drm_gem_object_handle_get_unlocked(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+
+ guard(mutex)(&dev->object
Patch "drm/gem: Acquire references on GEM handles for framebuffers" has been added to the 6.6-stable tree
This is a note to let you know that I've just added the patch titled
drm/gem: Acquire references on GEM handles for framebuffers
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:
drm-gem-acquire-references-on-gem-handles-for-framebuffers.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 know about it.
>From 5307dce878d4126e1b375587318955bd019c3741 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Mon, 30 Jun 2025 10:36:47 +0200
Subject: drm/gem: Acquire references on GEM handles for framebuffers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Thomas Zimmermann
commit 5307dce878d4126e1b375587318955bd019c3741 upstream.
A GEM handle can be released while the GEM buffer object is attached
to a DRM framebuffer. This leads to the release of the dma-buf backing
the buffer object, if any. [1] Trying to use the framebuffer in further
mode-setting operations leads to a segmentation fault. Most easily
happens with driver that use shadow planes for vmap-ing the dma-buf
during a page flip. An example is shown below.
[ 156.791968] [ cut here ]
[ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527
dma_buf_vmap+0x224/0x430
[...]
[ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430
[ 157.043420] Call Trace:
[ 157.045898]
[ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0
[ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0
[ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0
[ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710
[ 157.065567] ? dma_buf_vmap+0x224/0x430
[ 157.069446] ? __warn.cold+0x58/0xe4
[ 157.073061] ? dma_buf_vmap+0x224/0x430
[ 157.077111] ? report_bug+0x1dd/0x390
[ 157.080842] ? handle_bug+0x5e/0xa0
[ 157.084389] ? exc_invalid_op+0x14/0x50
[ 157.088291] ? asm_exc_invalid_op+0x16/0x20
[ 157.092548] ? dma_buf_vmap+0x224/0x430
[ 157.096663] ? dma_resv_get_singleton+0x6d/0x230
[ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10
[ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10
[ 157.110697] drm_gem_shmem_vmap+0x74/0x710
[ 157.114866] drm_gem_vmap+0xa9/0x1b0
[ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0
[ 157.123086] drm_gem_fb_vmap+0xab/0x300
[ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10
[ 157.133032] ? lockdep_init_map_type+0x19d/0x880
[ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0
[ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180
[ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40
[...]
[ 157.346424] ---[ end trace ]---
Acquiring GEM handles for the framebuffer's GEM buffer objects prevents
this from happening. The framebuffer's cleanup later puts the handle
references.
Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object
instance") triggers the segmentation fault easily by using the dma-buf
field more widely. The underlying issue with reference counting has
been present before.
v2:
- acquire the handle instead of the BO (Christian)
- fix comment style (Christian)
- drop the Fixes tag (Christian)
- rename err_ gotos
- add missing Link tag
Suggested-by: Christian König
Signed-off-by: Thomas Zimmermann
Link:
https://elixir.bootlin.com/linux/v6.15/source/drivers/gpu/drm/drm_gem.c#L241 #
[1]
Cc: Thomas Zimmermann
Cc: Anusha Srivatsa
Cc: Christian König
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc:
Reviewed-by: Christian König
Link: https://lore.kernel.org/r/20250630084001.293053-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_gem.c| 44 ---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 16 +
drivers/gpu/drm/drm_internal.h |2 +
3 files changed, 51 insertions(+), 11 deletions(-)
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -186,6 +186,35 @@ void drm_gem_private_object_fini(struct
}
EXPORT_SYMBOL(drm_gem_private_object_fini);
+static void drm_gem_object_handle_get(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+
+ drm_WARN_ON(dev, !mutex_is_locked(&dev->object_name_lock));
+
+ if (obj->handle_count++ == 0)
+ drm_gem_object_get(obj);
+}
+
+/**
+ * drm_gem_object_handle_get_unlocked - acquire reference on user-space handles
+ * @obj: GEM object
+ *
+ * Acquires a reference on the GEM buffer object's handle. Required
+ * to keep the GEM object alive. Call drm_gem_object_handle_put_unlocked()
+ * to release the reference.
+ */
+void drm_gem_object_handle_get_unlocked(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+
+ guard(mutex)(&dev->object_n
Re: [PATCH] misc: fastrpc: Use of_reserved_mem_region_to_resource() for "memory-region"
On 7/3/25 7:34 PM, Rob Herring (Arm) wrote:
> Use the newly added of_reserved_mem_region_to_resource() function to
> handle "memory-region" properties.
>
> The error handling is a bit different. "memory-region" is optional, so
> failed lookup is not an error. But then an error in
> of_reserved_mem_lookup() is treated as an error. However, that
> distinction is not really important. Either the region is available
> and usable or it is not. So now, it is just
> of_reserved_mem_region_to_resource() which is checked for an error.
>
> Signed-off-by: Rob Herring (Arm)
> ---
Reviewed-by: Srinivas Kandagatla
Greg, there are no more patches for fastrpc for this cycle, can you
please pick this up via char-misc tree?
thanks,
Srini
> drivers/misc/fastrpc.c | 19 +++
> 1 file changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index 378923594f02..53e88a1bc430 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c
> @@ -2262,8 +2262,6 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device
> *rpdev)
> int i, err, domain_id = -1, vmcount;
> const char *domain;
> bool secure_dsp;
> - struct device_node *rmem_node;
> - struct reserved_mem *rmem;
> unsigned int vmids[FASTRPC_MAX_VMIDS];
>
> err = of_property_read_string(rdev->of_node, "label", &domain);
> @@ -2306,20 +2304,17 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device
> *rpdev)
> }
> }
>
> - rmem_node = of_parse_phandle(rdev->of_node, "memory-region", 0);
> - if (domain_id == SDSP_DOMAIN_ID && rmem_node) {
> + if (domain_id == SDSP_DOMAIN_ID) {
> + struct resource res;
> u64 src_perms;
>
> - rmem = of_reserved_mem_lookup(rmem_node);
> - if (!rmem) {
> - err = -EINVAL;
> - goto err_free_data;
> - }
> + err = of_reserved_mem_region_to_resource(rdev->of_node, 0,
> &res);
> + if (!err) {
> + src_perms = BIT(QCOM_SCM_VMID_HLOS);
>
> - src_perms = BIT(QCOM_SCM_VMID_HLOS);
> -
> - qcom_scm_assign_mem(rmem->base, rmem->size, &src_perms,
> + qcom_scm_assign_mem(res.start, resource_size(&res),
> &src_perms,
> data->vmperms, data->vmcount);
> + }
>
> }
>
Re: linux-next: Tree for Jul 11 [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
On 7/12/25 3:11 AM, Rafael J. Wysocki wrote:
On Fri, Jul 11, 2025 at 11:25 PM Randy Dunlap wrote:
On 7/11/25 2:10 AM, Stephen Rothwell wrote:
Hi all,
Changes since 20250710:
on x86_64, when
# CONFIG_SUSPEND is not set
# CONFIG_HIBERNATION is not set
# CONFIG_PM is not set
ERROR: modpost: "pm_hibernate_is_recovering"
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
caused by commit
530694f54dd5e ("drm/amdgpu: do not resume device in thaw for normal
hibernation")
Rafael, is a stub appropriate for this case?
pm_hibernate_is_recovering() is not supposed to be called by code that
does not depend on CONFIG_HIBERNATE_CALLBACKS, but a stub returning
false would work for this.
Thanks, I just sent out a fix for this.
Mario, it would be good to fix this up in your tree. Also, it would
be good to expose stuff to 0-day build testing before letting it go
into linux-next. I use the bleeding-edge branch for this purpose.
Honestly; I'm surprised that 0-day didn't raise this on either dri-devel
or amd-gfx. I had expected at least one of those lists to raise this
over the last week of patches.
Anyone know the history why neither has 0-day?
Re: [PATCH] drm/bridge: it6505: select REGMAP_I2C
Can anyone help review this? It is a trivial build fix. On Tue, Jun 10, 2025 at 4:58 PM Chia-I Wu wrote: > > Fix > > aarch64-linux-gnu-ld: drivers/gpu/drm/bridge/ite-it6505.o: in function > `it6505_i2c_probe': > ite-it6505.c:(.text+0x754): undefined reference to `__devm_regmap_init_i2c' > > Signed-off-by: Chia-I Wu > --- > drivers/gpu/drm/bridge/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index b9e0ca85226a6..a6d6e62071a0e 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -122,6 +122,7 @@ config DRM_ITE_IT6505 > select EXTCON > select CRYPTO > select CRYPTO_HASH > + select REGMAP_I2C > help > ITE IT6505 DisplayPort bridge chip driver. > > -- > 2.50.0.rc0.642.g800a2b-goog >
[PATCH v2 2/3] panthor: save task pid and comm in panthor_group
We would like to report them on gpu errors.
We choose to save the info on panthor_group_create rather than on
panthor_open because, when the two differ, we are more interested in the
task that created the group.
Signed-off-by: Chia-I Wu
---
v2: save to panthor_group on panthor_group_create rather than to
panthor_file on panthor_open
---
drivers/gpu/drm/panthor/panthor_sched.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/panthor/panthor_sched.c
b/drivers/gpu/drm/panthor/panthor_sched.c
index a2248f692a030..823b0fe678ba6 100644
--- a/drivers/gpu/drm/panthor/panthor_sched.c
+++ b/drivers/gpu/drm/panthor/panthor_sched.c
@@ -641,6 +641,15 @@ struct panthor_group {
size_t kbo_sizes;
} fdinfo;
+ /** @task_info: Info of current->group_leader that created the group. */
+ struct {
+ /** @pid: pid of current->group_leader */
+ pid_t pid;
+
+ /** @comm: comm of current->group_leader */
+ char comm[TASK_COMM_LEN];
+ } task_info;
+
/** @state: Group state. */
enum panthor_group_state state;
@@ -3389,6 +3398,14 @@ group_create_queue(struct panthor_group *group,
return ERR_PTR(ret);
}
+static void group_init_task_info(struct panthor_group *group)
+{
+ struct task_struct *task = current->group_leader;
+
+ group->task_info.pid = task->pid;
+ get_task_comm(group->task_info.comm, task);
+}
+
static void add_group_kbo_sizes(struct panthor_device *ptdev,
struct panthor_group *group)
{
@@ -3540,6 +3557,8 @@ int panthor_group_create(struct panthor_file *pfile,
add_group_kbo_sizes(group->ptdev, group);
spin_lock_init(&group->fdinfo.lock);
+ group_init_task_info(group);
+
return gid;
err_put_group:
--
2.50.0.727.gbf7dc18ff4-goog
[PATCH v2 0/3] panthor: print task pid and comm on gpu errors
This series saves task pid and comm in panthor_group and prints task pid and comm on gpu errors. v2: save the task info in panthor_group on panthor_group_create, rather than in panthor_file on panthor_open, because, when the two differ, we are more interested in the task that created the group. Chia-I Wu (3): panthor: set owner field for driver fops panthor: save task pid and comm in panthor_group panthor: dump task pid and comm on gpu errors drivers/gpu/drm/panthor/panthor_drv.c | 14 ++-- drivers/gpu/drm/panthor/panthor_sched.c | 43 ++--- 2 files changed, 41 insertions(+), 16 deletions(-) -- 2.50.0.727.gbf7dc18ff4-goog
[PATCH v2 1/3] panthor: set owner field for driver fops
It allows us to get rid of manual try_module_get / module_put.
Signed-off-by: Chia-I Wu
Reviewed-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panthor/panthor_drv.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_drv.c
b/drivers/gpu/drm/panthor/panthor_drv.c
index 1116f2d2826ee..775a66c394544 100644
--- a/drivers/gpu/drm/panthor/panthor_drv.c
+++ b/drivers/gpu/drm/panthor/panthor_drv.c
@@ -1400,14 +1400,9 @@ panthor_open(struct drm_device *ddev, struct drm_file
*file)
struct panthor_file *pfile;
int ret;
- if (!try_module_get(THIS_MODULE))
- return -EINVAL;
-
pfile = kzalloc(sizeof(*pfile), GFP_KERNEL);
- if (!pfile) {
- ret = -ENOMEM;
- goto err_put_mod;
- }
+ if (!pfile)
+ return -ENOMEM;
pfile->ptdev = ptdev;
pfile->user_mmio.offset = DRM_PANTHOR_USER_MMIO_OFFSET;
@@ -1439,9 +1434,6 @@ panthor_open(struct drm_device *ddev, struct drm_file
*file)
err_free_file:
kfree(pfile);
-
-err_put_mod:
- module_put(THIS_MODULE);
return ret;
}
@@ -1454,7 +1446,6 @@ panthor_postclose(struct drm_device *ddev, struct
drm_file *file)
panthor_vm_pool_destroy(pfile);
kfree(pfile);
- module_put(THIS_MODULE);
}
static const struct drm_ioctl_desc panthor_drm_driver_ioctls[] = {
@@ -1555,6 +1546,7 @@ static void panthor_show_fdinfo(struct drm_printer *p,
struct drm_file *file)
}
static const struct file_operations panthor_drm_driver_fops = {
+ .owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
.unlocked_ioctl = drm_ioctl,
--
2.50.0.727.gbf7dc18ff4-goog
[PATCH v2 3/3] panthor: dump task pid and comm on gpu errors
It is useful to know which tasks cause gpu errors.
Signed-off-by: Chia-I Wu
---
drivers/gpu/drm/panthor/panthor_sched.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_sched.c
b/drivers/gpu/drm/panthor/panthor_sched.c
index 823b0fe678ba6..47912b06ec9d3 100644
--- a/drivers/gpu/drm/panthor/panthor_sched.c
+++ b/drivers/gpu/drm/panthor/panthor_sched.c
@@ -1364,8 +1364,12 @@ cs_slot_process_fatal_event_locked(struct panthor_device
*ptdev,
fatal = cs_iface->output->fatal;
info = cs_iface->output->fatal_info;
- if (group)
+ if (group) {
+ drm_warn(&ptdev->base, "CS_FATAL: pid=%d, comm=%s\n",
+group->task_info.pid, group->task_info.comm);
+
group->fatal_queues |= BIT(cs_id);
+ }
if (CS_EXCEPTION_TYPE(fatal) == DRM_PANTHOR_EXCEPTION_CS_UNRECOVERABLE)
{
/* If this exception is unrecoverable, queue a reset, and make
@@ -1425,6 +1429,11 @@ cs_slot_process_fault_event_locked(struct panthor_device
*ptdev,
spin_unlock(&queue->fence_ctx.lock);
}
+ if (group) {
+ drm_warn(&ptdev->base, "CS_FAULT: pid=%d, comm=%s\n",
+group->task_info.pid, group->task_info.comm);
+ }
+
drm_warn(&ptdev->base,
"CSG slot %d CS slot: %d\n"
"CS_FAULT.EXCEPTION_TYPE: 0x%x (%s)\n"
@@ -1641,11 +1650,15 @@ csg_slot_process_progress_timer_event_locked(struct
panthor_device *ptdev, u32 c
lockdep_assert_held(&sched->lock);
- drm_warn(&ptdev->base, "CSG slot %d progress timeout\n", csg_id);
-
group = csg_slot->group;
- if (!drm_WARN_ON(&ptdev->base, !group))
+ if (!drm_WARN_ON(&ptdev->base, !group)) {
+ drm_warn(&ptdev->base, "CSG_PROGRESS_TIMER_EVENT: pid=%d,
comm=%s\n",
+group->task_info.pid, group->task_info.comm);
+
group->timedout = true;
+ }
+
+ drm_warn(&ptdev->base, "CSG slot %d progress timeout\n", csg_id);
sched_queue_delayed_work(sched, tick, 0);
}
@@ -3227,7 +3240,8 @@ queue_timedout_job(struct drm_sched_job *sched_job)
struct panthor_scheduler *sched = ptdev->scheduler;
struct panthor_queue *queue = group->queues[job->queue_idx];
- drm_warn(&ptdev->base, "job timeout\n");
+ drm_warn(&ptdev->base, "job timeout: pid=%d, comm=%s, seqno=%llu\n",
+group->task_info.pid, group->task_info.comm,
job->done_fence->seqno);
drm_WARN_ON(&ptdev->base, atomic_read(&sched->reset.in_progress));
--
2.50.0.727.gbf7dc18ff4-goog
Re: [PATCH 2/4] panthor: save panthor_file in panthor_group
Hi, On Mon, Jun 23, 2025 at 2:07 AM Liviu Dudau wrote: > > On Mon, Jun 23, 2025 at 08:21:22AM +0200, Boris Brezillon wrote: > > On Fri, 20 Jun 2025 16:50:51 -0700 > > Chia-I Wu wrote: > > > > > We would like to access panthor_file from panthor_group on gpu errors. > > > Because panthour_group can outlive drm_file, add refcount to > > > panthor_file to ensure its lifetime. > > > > I'm not a huge fan of refcounting panthor_file because people tend to > > put resource they expect to be released when the last handle goes away, > > and if we don't refcount these sub-resources they might live longer > > than they are meant to. Also not a huge fan of the circular referencing > > that exists between file and groups after this change. > > > > How about we move the process info to a sub-object that's refcounted > > and let both panthor_file and panthor_group take a ref on this object > > instead? > > I agree with Boris on this. One alternative is to put the pid and comm in > the panthor_group struct as panthor_file makes no use of the fields. I took this suggestion in v2 because, when the task that opened the node differs from the task that created the group, we are more interested in the latter.
Re: [PATCH v2 2/3] panthor: save task pid and comm in panthor_group
Hi Chia-I, kernel test robot noticed the following build warnings: [auto build test WARNING on next-20250711] [also build test WARNING on v6.16-rc5] [cannot apply to linus/master v6.16-rc5 v6.16-rc4 v6.16-rc3] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Chia-I-Wu/panthor-set-owner-field-for-driver-fops/20250713-111248 base: next-20250711 patch link: https://lore.kernel.org/r/20250713030831.3227607-3-olvaffe%40gmail.com patch subject: [PATCH v2 2/3] panthor: save task pid and comm in panthor_group config: i386-buildonly-randconfig-003-20250713 (https://download.01.org/0day-ci/archive/20250713/202507131246.vxxazjgd-...@intel.com/config) compiler: gcc-12 (Debian 12.2.0-14+deb12u1) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250713/202507131246.vxxazjgd-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202507131246.vxxazjgd-...@intel.com/ All warnings (new ones prefixed by >>): Warning: drivers/gpu/drm/panthor/panthor_sched.c:317 Excess struct member 'runnable' description in 'panthor_scheduler' Warning: drivers/gpu/drm/panthor/panthor_sched.c:317 Excess struct member 'idle' description in 'panthor_scheduler' Warning: drivers/gpu/drm/panthor/panthor_sched.c:317 Excess struct member 'waiting' description in 'panthor_scheduler' Warning: drivers/gpu/drm/panthor/panthor_sched.c:317 Excess struct member 'has_ref' description in 'panthor_scheduler' Warning: drivers/gpu/drm/panthor/panthor_sched.c:317 Excess struct member 'in_progress' description in 'panthor_scheduler' Warning: drivers/gpu/drm/panthor/panthor_sched.c:317 Excess struct member 'stopped_groups' description in 'panthor_scheduler' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'mem' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'input' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'output' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'input_fw_va' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'output_fw_va' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'gpu_va' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'ref' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'gt' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'sync64' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'bo' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'offset' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'kmap' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'lock' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'id' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'seqno' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'last_fence' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'in_flight_jobs' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'slots' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'slot_count' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:489 Excess struct member 'seqno' description in 'panthor_queue' Warning: drivers/gpu/drm/panthor/panthor_sched.c:707 Excess struct member 'data' description in 'panthor_group' >> Warning: drivers/gpu/drm/panthor/panthor_sched.c:707 Excess struct member >> 'pid' description in 'panthor_group' >> Warning: drivers/gpu/drm/panthor/panthor_sched.c:707 Excess struct member >> 'comm' description in 'panthor_group' Warning: drivers/gpu/drm/panthor/panthor_sched.c:843 Excess struct member 'start' description in 'panthor_job' Warning: drivers/gpu/drm/panthor/panthor_sched.c:843 Excess struct memb
Re: linux-next: Tree for Jul 11 (drivers/gpu/drm/msm/msm_gem.c)
On 7/11/25 2:10 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20250710: on i386, when: CONFIG_DRM_MSM=y CONFIG_DRM_MSM_GPU_STATE=y CONFIG_DRM_MSM_GPU_SUDO=y # CONFIG_DRM_MSM_VALIDATE_XML is not set # CONFIG_DRM_MSM_MDP4 is not set # CONFIG_DRM_MSM_MDP5 is not set # CONFIG_DRM_MSM_DPU is not set so DRM_MSM_KMS is also not set: ../drivers/gpu/drm/msm/msm_gem.c: In function ‘msm_gem_vma_put’: ../drivers/gpu/drm/msm/msm_gem.c:106:54: error: invalid use of undefined type ‘struct msm_kms’ 106 | msm_gem_lock_vm_and_obj(&exec, obj, priv->kms->vm); | ^~ ../drivers/gpu/drm/msm/msm_gem.c:107:39: error: invalid use of undefined type ‘struct msm_kms’ 107 | put_iova_spaces(obj, priv->kms->vm, true, "vma_put"); | ^~ ../drivers/gpu/drm/msm/msm_gem.c: In function ‘is_kms_vm’: ../drivers/gpu/drm/msm/msm_gem.c:668:39: error: invalid use of undefined type ‘struct msm_kms’ 668 | return priv->kms && (priv->kms->vm == vm); | ^~ -- ~Randy
Re: [PATCH V1 4/9] dt-bindings: soc: xilinx: Add AI engine DT binding
On 11/07/2025 20:33, Williams, Gregory wrote: > + > +maintainers: > + - Gregory Williams > + > +description: > + The AMD AI Engine is a tile processor with many cores (up to 400) that > + can run in parallel. The data routing between cores is configured > through > + internal switches, and shim tiles interface with external > interconnect, such > + as memory or PL. One AI engine device can have multiple apertures, each > + has its own address space and interrupt. At runtime application can > create > + multiple partitions within an aperture which are groups of columns of > AI > + engine tiles. Each AI engine partition is the minimum resetable unit > for an > + AI engine application. > + > +properties: > + compatible: > +const: xlnx,ai-engine-v2.0 What does v2.0 stands for? Versioning is discouraged, unless mapping is well documented. >>> >>> Sure, I will remove the versioning in V2 patch. >> >> This should be specific to product, so use the actual product/model name. >> >> Is this part of a Soc? Then standard rules apply... but I could not >> deduce it from the descriptions or commit msgs. > > Yes this is part of an SoC. I will be more descriptive in V2 patch. Huh... so you MUST use SoC compatibles. Don't upstream things entirely different than everything else. Best regards, Krzysztof
Re: Kernel 6.16-rc5+: New warning from drivers/gpu/drm/drm_gem.c
Thanks, Simona.
On 11/07/2025 22:54, Simona Vetter wrote:
> On Fri, Jul 11, 2025 at 01:34:19PM +0100, Chris Clayton wrote:
>> Hi
>>
>> I've built and installed 6.16 cloned from Linus' tree and am consistently
>> getting a warning during system startup.
>> The warning is not produced by rc4 but is by rc5, so I've bisected between
>> those two points abd the outcome is:
>>
>> 5307dce878d4126e1b375587318955bd019c3741 is the first bad commit
>> commit 5307dce878d4126e1b375587318955bd019c3741 (HEAD)
>> Author: Thomas Zimmermann
>> Date: Mon Jun 30 10:36:47 2025 +0200
>>
>> drm/gem: Acquire references on GEM handles for framebuffers
>
> Should be sorted with f6bfc9afc751 ("drm/framebuffer: Acquire internal
> references on GEM handles"), and I'll just about to type the PR summary to
> send that to Linus.
> -Sima
>
I've just pulled, built and installed Linus's tree and can conform that the
warning I reported is no longer being output.
Thanks again.
Chris>>
>> A GEM handle can be released while the GEM buffer object is attached
>> to a DRM framebuffer. This leads to the release of the dma-buf backing
>> the buffer object, if any. [1] Trying to use the framebuffer in further
>> mode-setting operations leads to a segmentation fault. Most easily
>> happens with driver that use shadow planes for vmap-ing the dma-buf
>> during a page flip. An example is shown below.
>>
>> [ 156.791968] [ cut here ]
>> [ 156.796830] WARNING: CPU: 2 PID: 2255 at
>> drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430
>> [...]
>> [ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430
>> [ 157.043420] Call Trace:
>> [ 157.045898]
>> [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0
>> [ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0
>> [ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0
>> [ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710
>> [ 157.065567] ? dma_buf_vmap+0x224/0x430
>> [ 157.069446] ? __warn.cold+0x58/0xe4
>> [ 157.073061] ? dma_buf_vmap+0x224/0x430
>> [ 157.077111] ? report_bug+0x1dd/0x390
>> [ 157.080842] ? handle_bug+0x5e/0xa0
>> [ 157.084389] ? exc_invalid_op+0x14/0x50
>> [ 157.088291] ? asm_exc_invalid_op+0x16/0x20
>> [ 157.092548] ? dma_buf_vmap+0x224/0x430
>> [ 157.096663] ? dma_resv_get_singleton+0x6d/0x230
>> [ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10
>> [ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10
>> [ 157.110697] drm_gem_shmem_vmap+0x74/0x710
>> [ 157.114866] drm_gem_vmap+0xa9/0x1b0
>> [ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0
>> [ 157.123086] drm_gem_fb_vmap+0xab/0x300
>> [ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10
>> [ 157.133032] ? lockdep_init_map_type+0x19d/0x880
>> [ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0
>> [ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180
>> [ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40
>> [...]
>> [ 157.346424] ---[ end trace ]---
>>
>> Acquiring GEM handles for the framebuffer's GEM buffer objects prevents
>> this from happening. The framebuffer's cleanup later puts the handle
>> references.
>>
>> Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object
>> instance") triggers the segmentation fault easily by using the dma-buf
>> field more widely. The underlying issue with reference counting has
>> been present before.
>>
>> v2:
>> - acquire the handle instead of the BO (Christian)
>> - fix comment style (Christian)
>> - drop the Fixes tag (Christian)
>> - rename err_ gotos
>> - add missing Link tag
>>
>> Suggested-by: Christian König
>> Signed-off-by: Thomas Zimmermann
>> Link:
>> https://elixir.bootlin.com/linux/v6.15/source/drivers/gpu/drm/drm_gem.c#L241
>> # [1]
>> Cc: Thomas Zimmermann
>> Cc: Anusha Srivatsa
>> Cc: Christian König
>> Cc: Maarten Lankhorst
>> Cc: Maxime Ripard
>> Cc: Sumit Semwal
>> Cc: "Christian König"
>> Cc: linux-me...@vger.kernel.org
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: linaro-mm-...@lists.linaro.org
>> Cc:
>> Reviewed-by: Christian König
>> Link:
>> https://lore.kernel.org/r/20250630084001.293053-1-tzimmerm...@suse.de
>>
>> drivers/gpu/drm/drm_gem.c| 44
>>
>> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 16 +---
>> drivers/gpu/drm/drm_internal.h | 2 ++
>> 3 files changed, 51 insertions(+), 11 deletions(-)
>>
>> I've attached files that contain a full dmesg and the bisect log.
>>
>> If you require any additional diagnostics, just let me know, but please cc
>> me as I'm not subscribed.
>>
>> Chris
>
>> [0.00] Linux version 6.16.0-rc1+ (chris@laptop) (gcc (GCC) 15.1.1
>> 20250705, GNU ld (GNU Binutils) 2.44) #688
Re: [PATCH v7 02/10] accel/rocket: Add a new driver for Rockchip's NPU
On Fri, Jul 11, 2025 at 7:38 PM Andrew Davis wrote: > > On 6/6/25 1:28 AM, Tomeu Vizoso wrote: > > This initial version supports the NPU as shipped in the RK3588 SoC and > > described in the first part of its TRM, in Chapter 36. > > > > This NPU contains 3 independent cores that the driver can submit jobs > > to. > > > > This commit adds just hardware initialization and power management. > > > > v2: > > - Split cores and IOMMUs as independent devices (Sebastian Reichel) > > - Add some documentation (Jeffrey Hugo) > > - Be more explicit in the Kconfig documentation (Jeffrey Hugo) > > - Remove resets, as these haven't been found useful so far (Zenghui Yu) > > - Repack structs (Jeffrey Hugo) > > - Use DEFINE_DRM_ACCEL_FOPS (Jeffrey Hugo) > > - Use devm_drm_dev_alloc (Jeffrey Hugo) > > - Use probe log helper (Jeffrey Hugo) > > - Introduce UABI header in a later patch (Jeffrey Hugo) > > > > v3: > > - Adapt to a split of the register block in the DT bindings (Nicolas > >Frattaroli) > > - Move registers header to its own commit (Thomas Zimmermann) > > - Misc. cleanups (Thomas Zimmermann and Jeff Hugo) > > - Make use of GPL-2.0-only for the copyright notice (Jeff Hugo) > > - PM improvements (Nicolas Frattaroli) > > > > v4: > > - Use bulk clk API (Krzysztof Kozlowski) > > > > v6: > > - Remove mention to NVDLA, as the hardware is only incidentally related > >(Kever Yang) > > - Use calloc instead of GFP_ZERO (Jeff Hugo) > > - Explicitly include linux/container_of.h (Jeff Hugo) > > - pclk and npu clocks are now needed by all cores (Rob Herring) > > > > v7: > > - Assign its own IOMMU domain to each client, for isolation (Daniel > >Stone and Robin Murphy) > > > > Signed-off-by: Tomeu Vizoso > > --- > > Documentation/accel/index.rst| 1 + > > Documentation/accel/rocket/index.rst | 19 +++ > > MAINTAINERS | 10 ++ > > drivers/accel/Kconfig| 1 + > > drivers/accel/Makefile | 1 + > > drivers/accel/rocket/Kconfig | 25 > > drivers/accel/rocket/Makefile| 8 + > > drivers/accel/rocket/rocket_core.c | 70 + > > drivers/accel/rocket/rocket_core.h | 45 ++ > > drivers/accel/rocket/rocket_device.c | 25 > > drivers/accel/rocket/rocket_device.h | 26 > > drivers/accel/rocket/rocket_drv.c| 279 > > +++ > > drivers/accel/rocket/rocket_drv.h| 15 ++ > > 13 files changed, 525 insertions(+) > > > > diff --git a/Documentation/accel/index.rst b/Documentation/accel/index.rst > > index > > bc85f26533d88891dde482f91e26c1b22869..d8fa332d60a890dbb617454d2a26d9b6f9b196aa > > 100644 > > --- a/Documentation/accel/index.rst > > +++ b/Documentation/accel/index.rst > > @@ -10,6 +10,7 @@ Compute Accelerators > > introduction > > amdxdna/index > > qaic/index > > + rocket/index > > > > .. only:: subproject and html > > > > diff --git a/Documentation/accel/rocket/index.rst > > b/Documentation/accel/rocket/index.rst > > new file mode 100644 > > index > > ..300eb3aeab1d8c6514c65af4d216b2d5a1669131 > > --- /dev/null > > +++ b/Documentation/accel/rocket/index.rst > > @@ -0,0 +1,19 @@ > > +.. SPDX-License-Identifier: GPL-2.0-only > > + > > += > > + accel/rocket Rockchip NPU driver > > += > > + > > +The accel/rocket driver supports the Neural Processing Units (NPUs) inside > > some > > +Rockchip SoCs such as the RK3588. Rockchip calls it RKNN and sometimes > > RKNPU. > > + > > +The hardware is described in chapter 36 in the RK3588 TRM. > > + > > +This driver just powers the hardware on and off, allocates and maps > > buffers to > > +the device and submits jobs to the frontend unit. Everything else is done > > in > > +userspace, as a Gallium driver (also called rocket) that is part of the > > Mesa3D > > +project. > > + > > +Hardware currently supported: > > + > > +* RK3588 > > \ No newline at end of file > > diff --git a/MAINTAINERS b/MAINTAINERS > > index > > 96b82704950184bd71623ff41fc4df31e4c7fe87..2d8833bf1f2db06ca624d703f19066adab2f9fde > > 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -7263,6 +7263,16 @@ T: git > > https://gitlab.freedesktop.org/drm/misc/kernel.git > > F: drivers/accel/ivpu/ > > F: include/uapi/drm/ivpu_accel.h > > > > +DRM ACCEL DRIVER FOR ROCKCHIP NPU > > +M: Tomeu Vizoso > > +L: dri-devel@lists.freedesktop.org > > +S: Supported > > +T: git https://gitlab.freedesktop.org/drm/misc/kernel.git > > +F: Documentation/accel/rocket/ > > +F: Documentation/devicetree/bindings/npu/rockchip,rknn-core.yaml > > +F: drivers/accel/rocket/ > > +F: include/uapi/drm/rocket_accel.h > > + > > DRM COMPUTE ACCELERATORS DRIVERS AND FRAMEWORK > > M: Oded Gabbay > > L: dri-devel@lists.freedesktop.org > > diff --git a/drivers/accel/Kconfig b/drivers/accel/Kconfig > > index >
Re: linux-next: Tree for Jul 11 [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
On Fri, Jul 11, 2025 at 11:25 PM Randy Dunlap wrote:
>
>
>
> On 7/11/25 2:10 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20250710:
> >
>
> on x86_64, when
> # CONFIG_SUSPEND is not set
> # CONFIG_HIBERNATION is not set
> # CONFIG_PM is not set
>
> ERROR: modpost: "pm_hibernate_is_recovering"
> [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
>
> caused by commit
> 530694f54dd5e ("drm/amdgpu: do not resume device in thaw for normal
> hibernation")
>
> Rafael, is a stub appropriate for this case?
pm_hibernate_is_recovering() is not supposed to be called by code that
does not depend on CONFIG_HIBERNATE_CALLBACKS, but a stub returning
false would work for this.
Mario, it would be good to fix this up in your tree. Also, it would
be good to expose stuff to 0-day build testing before letting it go
into linux-next. I use the bleeding-edge branch for this purpose.
Re: [PATCH 0/9] rust: use `kernel::{fmt,prelude::fmt!}`
On Wed Jul 9, 2025 at 9:59 PM CEST, Tamir Duberstein wrote:
> This is series 2a/5 of the migration to `core::ffi::CStr`[0].
> 20250704-core-cstr-prepare-v1-0-a91524037...@gmail.com.
>
> This series depends on the prior series[0] and is intended to go through
> the rust tree to reduce the number of release cycles required to
> complete the work.
>
> Subsystem maintainers: I would appreciate your `Acked-by`s so that this
> can be taken through Miguel's tree (where the other series must go).
>
> [0]
> https://lore.kernel.org/all/20250704-core-cstr-prepare-v1-0-a91524037...@gmail.com/
>
> Signed-off-by: Tamir Duberstein
> ---
> Tamir Duberstein (9):
> gpu: nova-core: use `kernel::{fmt,prelude::fmt!}`
> rust: alloc: use `kernel::{fmt,prelude::fmt!}`
> rust: block: use `kernel::{fmt,prelude::fmt!}`
> rust: device: use `kernel::{fmt,prelude::fmt!}`
> rust: file: use `kernel::{fmt,prelude::fmt!}`
> rust: kunit: use `kernel::{fmt,prelude::fmt!}`
> rust: pin-init: use `kernel::{fmt,prelude::fmt!}`
> rust: seq_file: use `kernel::{fmt,prelude::fmt!}`
> rust: sync: use `kernel::{fmt,prelude::fmt!}`
>
> drivers/block/rnull.rs | 2 +-
> drivers/gpu/nova-core/gpu.rs | 3 +--
> drivers/gpu/nova-core/regs/macros.rs | 6 +++---
> rust/kernel/alloc/kbox.rs| 2 +-
> rust/kernel/alloc/kvec.rs| 2 +-
> rust/kernel/alloc/kvec/errors.rs | 2 +-
> rust/kernel/block/mq.rs | 2 +-
> rust/kernel/block/mq/gen_disk.rs | 2 +-
> rust/kernel/block/mq/raw_writer.rs | 3 +--
> rust/kernel/device.rs| 6 +++---
> rust/kernel/fs/file.rs | 5 +++--
> rust/kernel/init.rs | 4 ++--
> rust/kernel/kunit.rs | 8
> rust/kernel/seq_file.rs | 6 +++---
> rust/kernel/sync/arc.rs | 3 +--
> scripts/rustdoc_test_gen.rs | 2 +-
> 16 files changed, 28 insertions(+), 30 deletions(-)
For the entire series:
Reviewed-by: Benno Lossin
---
Cheers,
Benno
