[LTP] [PATCH v1] mmap21.c: Test for new MAP_DROPPABLE flag for mmap
Wei Gao
wegao@suse.com
Fri Jan 3 02:42:56 CET 2025
On Tue, Dec 31, 2024 at 06:04:54PM +0800, Li Wang wrote:
> On Sat, Dec 28, 2024 at 9:32 PM Wei Gao via ltp <ltp@lists.linux.it> wrote:
>
> > Signed-off-by: Wei Gao <wegao@suse.com>
> > ---
>
> + for (size_t i = 0; i < alloc_size; i += page_size) {
> > + if (!*(uint8_t *)(alloc + i)) {
> > + *shared_var = 1;
> > + break;
> > + }
> > + }
> > + }
> > +
> > + TST_EXP_EQ_LI((*shared_var), 1);
> >
>
> The test assumes that reclaimed MAP_DROPPABLE pages will be
> zeroed out when accessed. While this behavior is plausible, it depends
> on how MAP_DROPPABLE is implemented in the kernel.
>
> Do you have any clue (documents or code) that indicates this is true?
Thanks for your quick feedback , i will try to give clue for this:
1) Base the kernel commit message indicate memory will be zero.
commit 9651fcedf7b92d3f7f1ab179e8ab55b85ee10fc1
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date: Thu Dec 8 17:55:04 2022 +0100
These characteristics mean that we can introduce VM_DROPPABLE, which
has the following semantics:
a) It never is written out to swap.
b) Under memory pressure, mm can just drop the pages (so that they're
zero when read back again). <<<<<<<<<<<<<<<<<
c) It is inherited by fork.
d) It doesn't count against the mlock budget, since nothing is locked.
e) If there's not enough memory to service a page fault, it's not fatal,
and no signal is sent.
2) When kernel read back the dropped anonymous memory will trigger do_page_fault(),
finally it will reach do_anonymous_page() and hit following line:
https://elixir.bootlin.com/linux/v4.6/source/mm/memory.c#L2750
So normally you will read zeroed memory.
Call stack happen when read back:
do_page_fault()
↓
handle_mm_fault()
↓
__handle_mm_fault()
↓
handle_pte_fault()
↓
do_pte_missing()
↓
do_anonymous_page()
>
> --
> Regards,
> Li Wang
More information about the ltp
mailing list