From: "Liam R. Howlett" <Liam.Howlett@oracle.com>
To: jeffxu@chromium.org
Cc: akpm@linux-foundation.org, willy@infradead.org,
torvalds@linux-foundation.org, pedro.falcato@gmail.com,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-mm@kvack.org, linux-hardening@vger.kernel.org,
jeffxu@google.com, lorenzo.stoakes@oracle.com,
mpe@ellerman.id.au, oliver.sang@intel.com, vbabka@suse.cz,
keescook@chromium.org
Subject: Re: [PATCH v1 0/2] mremap refactor: check src address for vma boundaries first.
Date: Wed, 14 Aug 2024 10:39:56 -0400 [thread overview]
Message-ID: <slrsrycj73xrph5o2poicpt4cogpqw36bbwi5iqykvyce4pve3@suldmmv2mmo5> (raw)
In-Reply-To: <20240814071424.2655666-1-jeffxu@chromium.org>
* 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?
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/
next prev parent reply other threads:[~2024-08-14 14:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-14 7:14 jeffxu
2024-08-14 7:14 ` [PATCH v1 1/2] mseal:selftest mremap across VMA boundaries jeffxu
2024-08-14 7:14 ` [PATCH v1 2/2] mseal: refactor mremap to remove can_modify_mm jeffxu
2024-08-14 14:39 ` Liam R. Howlett [this message]
2024-08-14 16:57 ` [PATCH v1 0/2] mremap refactor: check src address for vma boundaries first Jeff Xu
2024-08-14 19:55 ` Liam R. Howlett
2024-08-15 3:45 ` Jeff Xu
2024-08-15 16:49 ` Liam R. Howlett
2024-08-15 17:22 ` Jeff Xu
2024-08-15 20:14 ` Liam R. Howlett
2024-08-15 20:23 ` Jeff Xu
2024-08-15 20:40 ` Liam R. Howlett
2024-08-15 18:16 ` Jeff Xu
2024-08-15 20:19 ` Jeff Xu
2024-08-16 2:39 ` Oliver Sang
2024-08-16 2:58 ` Jeff Xu
2024-08-18 9:28 ` Oliver Sang
2024-08-19 1:38 ` Oliver Sang
2024-08-19 6:35 ` Oliver Sang
2024-08-21 6:19 ` Oliver Sang
2024-08-21 15:21 ` Jeff Xu
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=slrsrycj73xrph5o2poicpt4cogpqw36bbwi5iqykvyce4pve3@suldmmv2mmo5 \
--to=liam.howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=jeffxu@chromium.org \
--cc=jeffxu@google.com \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mpe@ellerman.id.au \
--cc=oliver.sang@intel.com \
--cc=pedro.falcato@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox