All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: Andrea Cervesato <andrea.cervesato@suse.com>
Cc: Linux Test Project <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH 4/5] mremap04: Convert to new API
Date: Fri, 7 Aug 2026 09:59:53 +0200	[thread overview]
Message-ID: <anWQedSd9MwlSymD@yuki.lan> (raw)
In-Reply-To: <6a7579d4.5dfca4bd.124bf4.ac84@mx.google.com>

Hi!
> > > +	 * Pass old_size of one page while the segment is two pages: the
> > > +	 * mismatch is intentional and must be preserved.
> > >  	 */
> > 
> > Wouldn't this be enough for the mremap() to fail even with regular
> > mmap()? I do not see what the test needs the sysv shm for.
> 
> actually yes, but I think the original idea was to mix SysV with mremap()
> syscall.

I would keep this test simple.

And we can add another test with a gap as well. If we map 3 pages, then
unmap page in the middle we will get:

| page 0 | hole | page 2 |

Now remap without MAYMOVE on page0 that spans into page2 will fail too.

> > Also the interaction between SysV shm and mremap() seems to be more
> > complicated and may warrant more tests.
> 
> mmmh, any idea?

Looking stack overflow mremap() should be strictly local to the process.
That means that that SysV mapping or MAP_SHARED mappings shouldn't
change the mapping length in other processes sharing the mapping.
Strangely there does not seem to be much documentation for this. So it's
a corner case worth exploring (raised more than 10 years ago
https://lwn.net/Articles/591985/).

Also while reading the manual I found another possible test for mremap()
+ userfaultfd(). You should get a fault event for expanded mappings if
you access the expanded region.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2026-08-07  8:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-21 12:41 [LTP] [PATCH 0/5] Rewrite mremap testing suite Andrea Cervesato
2026-07-21 12:41 ` [LTP] [PATCH 1/5] mremap01: Convert to new API Andrea Cervesato
2026-07-21 13:53   ` [LTP] " linuxtestproject.agent
2026-08-06 11:45   ` [LTP] [PATCH 1/5] " Cyril Hrubis
2026-07-21 12:41 ` [LTP] [PATCH 2/5] mremap02: " Andrea Cervesato
2026-08-06 11:50   ` Cyril Hrubis
2026-07-21 12:41 ` [LTP] [PATCH 3/5] mremap03: " Andrea Cervesato
2026-08-06 11:58   ` Cyril Hrubis
2026-07-21 12:41 ` [LTP] [PATCH 4/5] mremap04: " Andrea Cervesato
2026-08-06 13:28   ` Cyril Hrubis
2026-08-07  6:23     ` Andrea Cervesato via ltp
2026-08-07  7:59       ` Cyril Hrubis [this message]
2026-08-07 12:24         ` Andrea Cervesato via ltp
2026-07-21 12:41 ` [LTP] [PATCH 5/5] mremap05: " Andrea Cervesato
2026-08-06 15:51   ` Cyril Hrubis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=anWQedSd9MwlSymD@yuki.lan \
    --to=chrubis@suse.cz \
    --cc=andrea.cervesato@suse.com \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.