Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] mm: mmap_action_finish bypasses error_override for compat tasks --
commit 21d3d0c977ac349611c733fc3c288ae67e5f71a1 Author: Lorenzo Stoakes (ARM) <[email protected]> mm: add mmap action for discontiguous kernel page mapping This commit introduces discontig_kernel_page_ops and a new mmap action type to allow drivers to map discontiguous arrays of kernel pages into a VMA. It updates the compatibility layer via compat_mmap_action_abort() to properly handle VMA teardown on mmap action failures. > diff --git a/mm/util.c b/mm/util.c > --- a/mm/util.c > +++ b/mm/util.c [ ... ] > @@ -1412,12 +1421,13 @@ static int mmap_action_finish(struct vm_area_struct > *vma, > > /* do_munmap() might take rmap lock, so release if held. */ > maybe_rmap_unlock_action(vma, action); > - /* > - * If this is invoked from the compatibility layer, post-mmap() hook > - * logic will handle cleanup for us. > - */ > - if (!err || is_compat) > + if (!err) > + return 0; > + > + if (is_compat) { > + compat_mmap_action_abort(vma); > return err; [Severity: Medium] Does this bypass the error_override logic for compat tasks? When an mmap action fails, the mmap_action struct provides an error_override field to allow drivers to replace the internal error code with a user-facing one. Later in this function, non-compat tasks return action->error_override ?: err. By returning err directly here when is_compat is true, it seems 32-bit compat tasks might receive different error codes than 64-bit tasks, potentially breaking ABI consistency. > + } > > /* > * If an error occurs, unmap the VMA altogether and return an error. We [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/20261013-b4-mmap-prepare-vma-flag-sanify-v6-0-1aa3c9b13...@kernel.org?part=8
