On Thu, Aug 29, 2024 at 5:09 AM Lorenzo Stoakes lorenzo.stoakes@oracle.com wrote:
Jeff... come on now.
Please cc- the reviewers of mm/mmap.c on these patches - that's me, Vlastimil and Liam. Same for mm/vma.c, mm/vma.h, mm/vma_internal.h.
sure, that was a small fix and I thought introduced by Pedro's commit (which was wrong)
And it seems like it should be pretty obvious you should cc- Liam when it's quite literally his code you're changing!
Relevant section from MAINTAINERS:
MEMORY MAPPING M: Andrew Morton akpm@linux-foundation.org R: Liam R. Howlett Liam.Howlett@oracle.com R: Vlastimil Babka vbabka@suse.cz R: Lorenzo Stoakes lorenzo.stoakes@oracle.com L: linux-mm@kvack.org S: Maintained W: http://www.linux-mm.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm F: mm/mmap.c
On Wed, Aug 28, 2024 at 10:55:21PM GMT, jeffxu@chromium.org wrote:
From: Jeff Xu jeffxu@chromium.org
mmap(MAP_FIXED) should return EPERM when memory is sealed.
Fixes: 4205a39e06da ("mm/munmap: replace can_modify_mm with can_modify_vma") Signed-off-by: Jeff Xu jeffxu@chromium.org
mm/mmap.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/mm/mmap.c b/mm/mmap.c index 80d70ed099cf..0cd0c0ef03c7 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1386,7 +1386,10 @@ unsigned long mmap_region(struct file *file, unsigned long addr, mt_on_stack(mt_detach); mas_init(&mas_detach, &mt_detach, /* addr = */ 0); /* Prepare to unmap any existing mapping in the area */
if (vms_gather_munmap_vmas(&vms, &mas_detach))
error = vms_gather_munmap_vmas(&vms, &mas_detach);if (error == -EPERM)return -EPERM;if (error) return -ENOMEM;Can't we just return the error here?
This is one for Liam, but I'm ostensibly in favour, this does seem valid!
vmg.next = vms.next;-- 2.46.0.295.g3b9ea8a38a-goog