[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <slrsrycj73xrph5o2poicpt4cogpqw36bbwi5iqykvyce4pve3@suldmmv2mmo5>
Date: Wed, 14 Aug 2024 10:39:56 -0400
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: jeffxu@...omium.org
Cc: akpm@...ux-foundation.org, willy@...radead.org,
torvalds@...ux-foundation.org, pedro.falcato@...il.com,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
linux-mm@...ck.org, linux-hardening@...r.kernel.org, jeffxu@...gle.com,
lorenzo.stoakes@...cle.com, mpe@...erman.id.au, oliver.sang@...el.com,
vbabka@...e.cz, keescook@...omium.org
Subject: Re: [PATCH v1 0/2] mremap refactor: check src address for vma
boundaries first.
* jeffxu@...omium.org <jeffxu@...omium.org> [240814 03:14]:
> From: Jeff Xu <jeffxu@...omium.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?
Maybe send your selftest to be included with the initial patch set would
work? Does this test pass with the other patch set?
[1] https://lore.kernel.org/all/CALmYWFs0v07z5vheDt1h3hD+3--yr6Va0ZuQeaATo+-8MuRJ-g@mail.mail.com/
Powered by blists - more mailing lists