On Wed, Aug 14, 2024 at 7:40 AM Liam R. Howlett Liam.Howlett@oracle.com wrote:
- jeffxu@chromium.org jeffxu@chromium.org [240814 03:14]:
From: Jeff Xu jeffxu@chromium.org
mremap doesn't allow relocate, expand, shrink across VMA boundaries, refactor the code to check src address range before doing anything on the destination, i.e. destination won't be unmapped, if src address failed the boundaries check.
This also allows us to remove can_modify_mm from mremap.c, since the src address must be single VMA, can_modify_vma is used.
I don't think sending out a separate patch to address the same thing as the patch you said you were testing [1] is the correct approach. You had already sent suggestions on mremap changes - why send this patch set instead of making another suggestion?
As indicated in the cover letter, this patch aims to improve mremap performance while preserving existing mseal's semantics. And this patch can go in-dependantly regardless of in-loop out-loop discussion.
[1] link in your email is broken, but I assume you meant Pedro's V1/V2 of in-loop change. In-loop change has a semantic/regression risk to mseal, and will take longer time to review/test/prove and bake.
We can leave in-loop discussion in Pedro's thread, I hope the V3 of Pedro's patch adds more testing coverage and addresses existing comments in V2.
Thanks -Jeff
-Jeff