From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,willy@infradead.org,usama.anjum@collabora.com,torvalds@linux-foundation.org,surenb@google.com,sroettger@google.com,shuah@kernel.org,pedro.falcato@gmail.com,Liam.Howlett@oracle.com,keescook@chromium.org,jorgelo@chromium.org,jeffxu@google.com,javier.carrasco.cruz@gmail.com,jannh@google.com,groeck@chromium.org,gregkh@linuxfoundation.org,dave.hansen@intel.com,corbet@lwn.net,amer.shanawany@gmail.com,jeffxu@chromium.org,akpm@linux-foundation.org
Subject: [folded-merged] mseal-add-mseal-syscall-fix.patch removed from -mm tree
Date: Sat, 11 May 2024 14:49:14 -0700 [thread overview]
Message-ID: <20240511214915.79A5AC32781@smtp.kernel.org> (raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5083 bytes --]
The quilt patch titled
Subject: mseal: add branch prediction hint
has been removed from the -mm tree. Its filename was
mseal-add-mseal-syscall-fix.patch
This patch was dropped because it was folded into mseal-add-mseal-syscall.patch
------------------------------------------------------
From: Jeff Xu <jeffxu@chromium.org>
Subject: mseal: add branch prediction hint
Date: Tue, 23 Apr 2024 19:28:25 +0000
It is unlikely that application calls mm syscall, such as mprotect, on
already sealed mappings, adding branch prediction hint.
Link: https://lkml.kernel.org/r/20240423192825.1273679-2-jeffxu@chromium.org
Signed-off-by: Jeff Xu <jeffxu@chromium.org>
Suggested-by: Pedro Falcato <pedro.falcato@gmail.com>
Cc: Amer Al Shanawany <amer.shanawany@gmail.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Jann Horn <jannh@google.com>
Cc: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Cc: Jeff Xu <jeffxu@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Stephen Röttger <sroettger@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/madvise.c | 2 +-
mm/mmap.c | 4 ++--
mm/mprotect.c | 2 +-
mm/mremap.c | 4 ++--
mm/mseal.c | 6 +++---
5 files changed, 9 insertions(+), 9 deletions(-)
--- a/mm/madvise.c~mseal-add-mseal-syscall-fix
+++ a/mm/madvise.c
@@ -1449,7 +1449,7 @@ int do_madvise(struct mm_struct *mm, uns
* Check if the address range is sealed for do_madvise().
* can_modify_mm_madv assumes we have acquired the lock on MM.
*/
- if (!can_modify_mm_madv(mm, start, end, behavior)) {
+ if (unlikely(!can_modify_mm_madv(mm, start, end, behavior))) {
error = -EPERM;
goto out;
}
--- a/mm/mmap.c~mseal-add-mseal-syscall-fix
+++ a/mm/mmap.c
@@ -2740,7 +2740,7 @@ int do_vmi_munmap(struct vma_iterator *v
* Prevent unmapping a sealed VMA.
* can_modify_mm assumes we have acquired the lock on MM.
*/
- if (!can_modify_mm(mm, start, end))
+ if (unlikely(!can_modify_mm(mm, start, end)))
return -EPERM;
/* arch_unmap() might do unmaps itself. */
@@ -3163,7 +3163,7 @@ int do_vma_munmap(struct vma_iterator *v
* Prevent unmapping a sealed VMA.
* can_modify_mm assumes we have acquired the lock on MM.
*/
- if (!can_modify_mm(mm, start, end))
+ if (unlikely(!can_modify_mm(mm, start, end)))
return -EPERM;
arch_unmap(mm, start, end);
--- a/mm/mprotect.c~mseal-add-mseal-syscall-fix
+++ a/mm/mprotect.c
@@ -749,7 +749,7 @@ static int do_mprotect_pkey(unsigned lon
* checking if memory is sealed.
* can_modify_mm assumes we have acquired the lock on MM.
*/
- if (!can_modify_mm(current->mm, start, end)) {
+ if (unlikely(!can_modify_mm(current->mm, start, end))) {
error = -EPERM;
goto out;
}
--- a/mm/mremap.c~mseal-add-mseal-syscall-fix
+++ a/mm/mremap.c
@@ -912,7 +912,7 @@ static unsigned long mremap_to(unsigned
*
* can_modify_mm assumes we have acquired the lock on MM.
*/
- if (!can_modify_mm(mm, addr, addr + old_len))
+ if (unlikely(!can_modify_mm(mm, addr, addr + old_len)))
return -EPERM;
if (flags & MREMAP_FIXED) {
@@ -1087,7 +1087,7 @@ SYSCALL_DEFINE5(mremap, unsigned long, a
* Place can_modify_mm here so we can keep the logic related to
* shrink/expand together.
*/
- if (!can_modify_mm(mm, addr, addr + old_len)) {
+ if (unlikely(!can_modify_mm(mm, addr, addr + old_len))) {
ret = -EPERM;
goto out;
}
--- a/mm/mseal.c~mseal-add-mseal-syscall-fix
+++ a/mm/mseal.c
@@ -32,7 +32,7 @@ static inline void set_vma_sealed(struct
*/
static bool can_modify_vma(struct vm_area_struct *vma)
{
- if (vma_is_sealed(vma))
+ if (unlikely(vma_is_sealed(vma)))
return false;
return true;
@@ -75,7 +75,7 @@ bool can_modify_mm(struct mm_struct *mm,
/* going through each vma to check. */
for_each_vma_range(vmi, vma, end) {
- if (!can_modify_vma(vma))
+ if (unlikely(!can_modify_vma(vma)))
return false;
}
@@ -100,7 +100,7 @@ bool can_modify_mm_madv(struct mm_struct
/* going through each vma to check. */
for_each_vma_range(vmi, vma, end)
- if (is_ro_anon(vma) && !can_modify_vma(vma))
+ if (unlikely(is_ro_anon(vma) && !can_modify_vma(vma)))
return false;
/* Allow by default. */
_
Patches currently in -mm which might be from jeffxu@chromium.org are
mseal-wire-up-mseal-syscall.patch
mseal-add-mseal-syscall.patch
selftest-mm-mseal-memory-sealing.patch
mseal-add-documentation.patch
selftest-mm-mseal-read-only-elf-memory-segment.patch
selftest-mm-mseal-read-only-elf-memory-segment-fix.patch
selftest-mm-mseal-read-only-elf-memory-segment-fix-3.patch
selftest-mm-mseal-read-only-elf-memory-segment-fix-4.patch
reply other threads:[~2024-05-11 21:49 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20240511214915.79A5AC32781@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=Liam.Howlett@oracle.com \
--cc=amer.shanawany@gmail.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=groeck@chromium.org \
--cc=jannh@google.com \
--cc=javier.carrasco.cruz@gmail.com \
--cc=jeffxu@chromium.org \
--cc=jeffxu@google.com \
--cc=jorgelo@chromium.org \
--cc=keescook@chromium.org \
--cc=mm-commits@vger.kernel.org \
--cc=pedro.falcato@gmail.com \
--cc=shuah@kernel.org \
--cc=sroettger@google.com \
--cc=surenb@google.com \
--cc=torvalds@linux-foundation.org \
--cc=usama.anjum@collabora.com \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).