From: sashiko-bot@kernel.org
To: "Matthew Brost" <matthew.brost@intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/pagemap: Add fault injection for higher-order RAM folio allocation
Date: Wed, 05 Aug 2026 11:51:49 +0000 [thread overview]
Message-ID: <20260805115150.656191F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260805113338.3742178-5-matthew.brost@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The debugfs entry created for fault injection is not removed on module unload, leading to a memory leak and a use-after-free vulnerability.
--
--- Patch [4]: [PATCH 4/4] drm/pagemap: Add fault injection for higher-order RAM folio allocation ---
commit 20731b2cfca08a84398b3c52bd2ca16474a3a4f7
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 the failure
of higher-order allocations in drm_pagemap_migrate_populate_ram_pfn().
The feature is exposed via a debugfs entry.
> diff --git a/drivers/gpu/drm/drm_pagemap.c b/drivers/gpu/drm/drm_pagemap.c
> index 7610e233d238c..01eb29ef023ce 100644
> --- a/drivers/gpu/drm/drm_pagemap.c
> +++ b/drivers/gpu/drm/drm_pagemap.c
[ ... ]
> @@ -1540,6 +1564,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);
[Severity: High]
Does this code leave dangling debugfs entries on module unload?
In drm_pagemap_module_init(), fault_create_debugfs_attr() creates the
drm_pagemap_fault_inject debugfs directory, which holds pointers to the
migrate_to_ram_fault_inject struct located in the module's .data section.
However, drm_pagemap_exit() doesn't seem to clean this up by tracking the
dentry and calling debugfs_remove_recursive(). When the module is
unloaded, the memory backing the fault attribute is freed, but the debugfs
files remain.
Could reading or writing to these lingering debugfs files after the
module is unloaded trigger a use-after-free?
> if (WARN_ON(!llist_empty(&drm_pagemap_unhold_list)))
> disable_work_sync(&drm_pagemap_work);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260805113338.3742178-1-matthew.brost@intel.com?part=4
next prev parent reply other threads:[~2026-08-05 11:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 11:33 [PATCH 0/4] Fix device page migration in low memory fallback Matthew Brost
2026-08-05 11:33 ` [PATCH 1/4] mm/migrate_device: Fix THP splitting of a CPU faulted device private folio Matthew Brost
2026-08-05 11:33 ` [PATCH 2/4] mm/migrate_device: Apply the fault reference to the correct folio Matthew Brost
2026-08-05 11:54 ` sashiko-bot
2026-08-05 11:33 ` [PATCH 3/4] drm/pagemap: Fix folio allocation fallback and use-after-put Matthew Brost
2026-08-05 11:47 ` sashiko-bot
2026-08-05 11:33 ` [PATCH 4/4] drm/pagemap: Add fault injection for higher-order RAM folio allocation Matthew Brost
2026-08-05 11:51 ` sashiko-bot [this message]
2026-08-05 15:22 ` ✗ CI.checkpatch: warning for Fix device page migration in low memory fallback Patchwork
2026-08-05 15:23 ` ✓ CI.KUnit: success " Patchwork
2026-08-05 15:59 ` ✓ Xe.CI.BAT: " 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=20260805115150.656191F000E9@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.