On Tue, Aug 6, 2024 at 11:25 PM Jeff Xu <jeffxu@xxxxxxxxxx> wrote: > > On Tue, Aug 6, 2024 at 2:28 PM Pedro Falcato <pedro.falcato@xxxxxxxxx> wrote: > > > > Optimize mseal checks by removing the separate can_modify_mm() step, and > > just doing checks on the individual vmas, when various operations are > > themselves iterating through the tree. This provides a nice speedup. > > > > While I was at it, I found that is_madv_discard() was completely bogus. > > > Thanks for catching this! > Is it possible to separate this fix out from this series and send it > separately and merge first ? Sure. This series is definitely too risky to catch this release, so sending it out as a fix (tomorrow, it's late here) sounds ok. > > > Note that my series ignores arch_unmap(), which seems to generally be what we're trending towards[2]. It should > > be applied on top of any powerpc vdso ->close patch to avoid regressions on the PPC architecture. No other > > architecture seems to use arch_unmap. > > > > Note2: This series does not pass all mseal_tests on my end (test_seal_mremap_move_dontunmap_anyaddr fails twice). But the > > top of Linus's tree does not pass these for me either (neither does my Arch Linux 6.10.2 kernel), > > for some reason (mremap regression?). > > > I just sync to Linus's main and I was able to run the test (except two > pkeys related test are skipped because I m on VM) Okay. Fun bug. I was really confused as to why no one could repro this except me :) It looks like recently[1] glibc started consuming the new_address variadic argument when MREMAP_DONTUNMAP. As to the why, MREMAP_DONTUNMAP also seems to take new_address as a hint (this is not documented in the man page, and strace also doesn't know this). However, this trips up some checks that were always fine before (because glibc always passed NULL, and musl still does): if (offset_in_page(new_addr)) if (new_len > TASK_SIZE || new_addr > TASK_SIZE - new_len) if (addr + old_len > new_addr && new_addr + new_len > addr) ^^ These all look at the address without looking at MREMAP_FIXED, and return -EINVAL if they fail. So, test_seal_mremap_move_dontunmap_anyaddr passes 0xdeadbeef For Some Reason (why are you testing mremap in mseal_test.c??), it trips up offset_in_page(new_addr) in mremap_to, and we crash and burn. As to why no one else could repro this: I guess you're not running a glibc new enough ;) [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=6c40cb0e9f893d49dc7caee580a055de53562206 -- Pedro
