Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] Build failure on NOMMU architectures due to unconditional use of mmput_async() --
commit dc8e122093c744c8bd5d72581571fdb0ccb6856c Author: Srinivasan Shanmugam <[email protected]> drm: Add drm_user_fence helper Introduce a common DRM user fence helper providing the kref-managed, MM-borrowing dma-fence-callback-to-workqueue pattern used by drivers that must access userspace memory from a kthread context when a GPU fence signals. > diff --git a/drivers/gpu/drm/drm_user_fence.c > b/drivers/gpu/drm/drm_user_fence.c > new file mode 100644 > index 0000000000000..f7882208a8b73 > --- /dev/null > +++ b/drivers/gpu/drm/drm_user_fence.c [ ... ] > +static void drm_user_fence_do_work(struct drm_work_fence *wfence) > +{ > + struct drm_user_fence *ufence = > + container_of(wfence, struct drm_user_fence, base); > + struct mm_struct *mm = NULL; > + > + if (mmget_not_zero(ufence->mm)) { > + mm = ufence->mm; > + kthread_use_mm(mm); > + } > + > + ufence->ops->writeback(ufence, !!mm); > + > + if (mm) { > + kthread_unuse_mm(mm); > + mmput_async(mm); /* requires CONFIG_MMU — GPU requires > MMU */ [Severity: Low] Does this cause a build failure on architectures where CONFIG_MMU is disabled? Although the comment notes that GPUs require an MMU, the DRM core and this file are compiled unconditionally as part of CONFIG_DRM. Calling mmput_async() here without an #ifdef CONFIG_MMU guard or similar protection could result in an implicit function declaration or linker error on NOMMU builds. > + } > +} > + -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
