From: sashiko-bot@kernel.org
To: "Matthew Brost" <matthew.brost@intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 6/6] drm/pagemap: Add fault injection for higher-order RAM folio allocation
Date: Wed, 05 Aug 2026 23:24:48 +0000 [thread overview]
Message-ID: <20260805232449.6C0551F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260805231041.3791771-7-matthew.brost@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Use-After-Free in debugfs due to missing cleanup on module unload.
--
--- Patch [6]: [PATCH v3 6/6] drm/pagemap: Add fault injection for higher-order RAM folio allocation ---
commit fdb5d198639794ed363bbe0eda839a0e39a16e0c
Author: Matthew Brost <matthew.brost@intel.com>
drm/pagemap: Add fault injection for higher-order RAM folio allocation
This commit introduces a fault injection attribute to simulate memory
pressure for higher-order RAM folio allocations. It adds a debugfs entry
to allow testing the order-0 fallback and THP split paths in
__migrate_device_pages().
> diff --git a/drivers/gpu/drm/drm_pagemap.c b/drivers/gpu/drm/drm_pagemap.c
> --- a/drivers/gpu/drm/drm_pagemap.c
> +++ b/drivers/gpu/drm/drm_pagemap.c
[ ... ]
> @@ -1554,6 +1578,16 @@ void drm_pagemap_destroy(struct drm_pagemap *dpagemap, bool is_atomic_or_reclaim
> kfree(dpagemap);
> }
>
> +static int __init drm_pagemap_module_init(void)
> +{
> +#if defined(CONFIG_DEBUG_FS) && defined(CONFIG_FAULT_INJECTION)
> + fault_create_debugfs_attr("drm_pagemap_fault_inject", NULL,
> + &migrate_to_ram_fault_inject);
> +#endif
> + return 0;
> +}
> +module_init(drm_pagemap_module_init);
> +
> static void drm_pagemap_exit(void)
> {
> flush_work(&drm_pagemap_work);
> if (WARN_ON(!llist_empty(&drm_pagemap_unhold_list)))
> disable_work_sync(&drm_pagemap_work);
> }
[Severity: High]
Does this leak the debugfs directory on module unload, potentially leading
to a use-after-free?
In drm_pagemap_module_init(), fault_create_debugfs_attr() creates a debugfs
entry pointing to migrate_to_ram_fault_inject, which resides in the module's
memory. Since the returned dentry isn't saved and removed here in
drm_pagemap_exit(), the debugfs entry will remain active after the module is
unloaded.
If the debugfs files are accessed post-unload, could the kernel dereference
the freed fault_attr pointer? Should the dentry be captured during init and
cleaned up in the exit function?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260805231041.3791771-1-matthew.brost@intel.com?part=6
next prev parent reply other threads:[~2026-08-05 23:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 23:10 [PATCH v3 0/6] Fix device page migration in low memory fallback Matthew Brost
2026-08-05 23:10 ` [PATCH v3 1/6] mm/migrate_device: Clear stale mapping after freeing swapcache Matthew Brost
2026-08-05 23:22 ` sashiko-bot
2026-08-05 23:10 ` [PATCH v3 2/6] mm/migrate_device: Do not write past the end of the src_pfns array Matthew Brost
2026-08-05 23:25 ` sashiko-bot
2026-08-05 23:29 ` Balbir Singh
2026-08-05 23:10 ` [PATCH v3 3/6] mm/migrate_device: Fix THP splitting of a CPU faulted device private folio Matthew Brost
2026-08-06 8:10 ` Balbir Singh
2026-08-10 2:26 ` Huang, Ying
2026-08-10 19:43 ` Matthew Brost
2026-08-05 23:10 ` [PATCH v3 4/6] drm/pagemap: dma-unmap pages before handling migration errors Matthew Brost
2026-08-05 23:22 ` sashiko-bot
2026-08-05 23:10 ` [PATCH v3 5/6] drm/pagemap: Fix folio allocation fallback and use-after-put Matthew Brost
2026-08-05 23:10 ` [PATCH v3 6/6] drm/pagemap: Add fault injection for higher-order RAM folio allocation Matthew Brost
2026-08-05 23:24 ` sashiko-bot [this message]
2026-08-05 23:17 ` ✗ CI.checkpatch: warning for Fix device page migration in low memory fallback (rev3) Patchwork
2026-08-05 23:18 ` ✓ CI.KUnit: success " Patchwork
2026-08-06 0:02 ` ✓ Xe.CI.BAT: " Patchwork
2026-08-06 9:15 ` ✓ Xe.CI.FULL: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260805232449.6C0551F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.