From: sashiko-bot@kernel.org
To: "Arvind Yadav" <arvind.yadav@intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [RFC v3 6/7] drm/xe/vm: Wire MADVISE_AUTORESET notifiers into VM lifecycle
Date: Thu, 04 Jun 2026 10:05:53 +0000 [thread overview]
Message-ID: <20260604100553.70AE91F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260604095012.367231-7-arvind.yadav@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unbounded kernel memory leak of `xe_madvise_notifier` structures due to missing cleanup on VMA unbind.
--
commit 842ee67ad0fcd26bd2723ff015ee6cb68da543ef
Author: Arvind Yadav <arvind.yadav@intel.com>
drm/xe/vm: Wire MADVISE_AUTORESET notifiers into VM lifecycle
This commit initializes the MADVISE_AUTORESET notifier infrastructure for
fault-mode VMs and handles tear down during VM close. It also collects CPU
mirror VMA ranges to register interval notifiers after dropping the VM lock.
> diff --git a/drivers/gpu/drm/xe/xe_vm_madvise.c b/drivers/gpu/drm/xe/xe_vm_madvise.c
> --- a/drivers/gpu/drm/xe/xe_vm_madvise.c
> +++ b/drivers/gpu/drm/xe/xe_vm_madvise.c
[ ... ]
> @@ -731,6 +806,30 @@ int xe_vm_madvise_ioctl(struct drm_device *dev, void *data, struct drm_file *fil
> unlock_vm:
> up_write(&vm->lock);
>
> + if (!err) {
> + for (int i = 0; i < num_notifier_ranges; i++) {
> + int ret = xe_vm_madvise_register_notifier_range(vm,
> + notifier_ranges[i].start,
> + notifier_ranges[i].end);
[Severity: High]
Does this code leak xe_madvise_notifier structures if the VMA is
subsequently unbound?
When userspace calls the MADVISE ioctl on a CPU mirror VMA,
xe_vm_madvise_register_notifier_range() allocates a new notifier and
adds it to the VM madvise_notifier_list.
However, there does not appear to be a hook in the VMA teardown path,
such as xe_vma_destroy(), to remove notifiers associated with a
destroyed GPU VMA. The notifiers are only freed when the entire VM is
destroyed in xe_vm_madvise_fini(), or if they are fully covered by a
newly registered notifier.
Could a userspace application repeatedly bind a VMA, call the MADVISE
ioctl, and unbind the VMA, shifting the address range slightly each
time, to indefinitely accumulate xe_madvise_notifier objects and mmu
interval notifiers until it triggers an out of memory condition?
> + if (ret) {
> + drm_warn(&vm->xe->drm,
> + "Failed to register madvise notifier [%#llx-%#llx]: %d\n",
> + notifier_ranges[i].start,
> + notifier_ranges[i].end, ret);
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260604095012.367231-1-arvind.yadav@intel.com?part=6
next prev parent reply other threads:[~2026-06-04 10:05 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-04 9:50 [RFC v3 0/7] drm/xe/svm: Add MMU notifier-based madvise autoreset on munmap Arvind Yadav
2026-06-04 9:50 ` [RFC v3 1/7] drm/xe/vm: Track CPU_AUTORESET state in xe_vma Arvind Yadav
2026-06-04 9:50 ` [RFC v3 2/7] drm/xe/vm: Preserve cpu_autoreset_active across GPUVA operations Arvind Yadav
2026-06-04 10:07 ` sashiko-bot
2026-06-04 9:50 ` [RFC v3 3/7] drm/xe/svm: Clear CPU_AUTORESET_ACTIVE on first GPU fault Arvind Yadav
2026-06-04 9:50 ` [RFC v3 4/7] drm/xe/vm: Add madvise autoreset notifier worker Arvind Yadav
2026-06-04 10:14 ` sashiko-bot
2026-06-04 9:50 ` [RFC v3 5/7] drm/xe/vm: Disable madvise notifier on GPU touch Arvind Yadav
2026-06-04 10:03 ` sashiko-bot
2026-06-04 9:50 ` [RFC v3 6/7] drm/xe/vm: Wire MADVISE_AUTORESET notifiers into VM lifecycle Arvind Yadav
2026-06-04 10:05 ` sashiko-bot [this message]
2026-06-04 9:50 ` [RFC v3 7/7] drm/xe/svm: Correct memory attribute reset for partial unmap Arvind Yadav
2026-06-04 10:12 ` sashiko-bot
2026-06-04 10:32 ` ✗ CI.checkpatch: warning for drm/xe/svm: Add MMU notifier-based madvise autoreset on munmap (rev3) Patchwork
2026-06-04 10:34 ` ✓ CI.KUnit: success " Patchwork
2026-06-04 11:35 ` ✓ Xe.CI.BAT: " Patchwork
2026-06-05 0:02 ` ✗ Xe.CI.FULL: failure " 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=20260604100553.70AE91F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=arvind.yadav@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--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.