From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>,
Benjamin Tissoires <bentiss@kernel.org>,
Jiri Kosina <jikos@kernel.org>,
Uladzislau Rezki <urezki@gmail.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, stable@vger.kernel.org
Subject: [PATCH 0/5] mm/execmem: fixes and cleanups for the ROX cache
Date: Thu, 03 Sep 2026 18:49:57 +0300 [thread overview]
Message-ID: <20260903-execmem-rox-cache-pmd-v1-v1-0-11beb2a3d249@kernel.org> (raw)
Sashiko review of the ROX cache refill path asked what happens when the
PMD_SIZE allocation fails there. Pulling that thread uncovered a bit
more than the fallback.
Patch 1 fixes a real bug, although rare bug: execmem_cache_clean() can
free a chunk that is still partially in use, because a PMD sized and PMD
aligned free range in the middle of a larger chunk looks exactly like a
chunk that nobody uses.
Patch 2 handles maple tree allocation failures in the cache. They are
unlikely, but silently dropping an area from the tree is not a great way
to deal with them.
Patch 3 deals with the fallback that started all this. The cache exists to
keep the direct map free of unnecessary splits, and the fallback happily
filled it with base page mapped areas that could never be freed from the
cache again. Ask vmalloc for a huge mapping or nothing, and serve whatever
does not fit outside the cache.
Patches 4 and 5 convert the ROX cache to scope based cleanup.
The series was tested on x86 with module load/unload cycles, with PTDUMP
confirming that the cache is using 2M mappings, and with nohugevmalloc
to exercise the uncached fallback.
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
---
Mike Rapoport (Microsoft) (5):
mm/execmem: free ROX cache chunks only when they span an entire vm area
mm/execmem: handle potential allocation errors in the maple tree
mm/execmem: make sure ROX cache always contains multiples of PMD_SIZE
mm/vmalloc: add DEFINE_FREE() for vfree()
mm/execmem: use cleanup infrastructure in ROX cache functions
drivers/hid/hid-core.c | 4 +-
include/linux/vmalloc.h | 4 ++
mm/execmem.c | 124 ++++++++++++++++++++++++++++--------------------
mm/vmalloc.c | 15 +++++-
4 files changed, 92 insertions(+), 55 deletions(-)
---
base-commit: 8499b4645c7f199707510461779f82d85732e742
change-id: 20260903-execmem-rox-cache-pmd-v1-ab97da2c4364
prerequisite-change-id: 20260816-execmem-set-vm-perms-v0-2-bae847a4f64f:v3
prerequisite-patch-id: 4d8c7989581fd5f4aaa2e315bfc903a9f0aadedc
prerequisite-patch-id: 211c002f2501d5aad7dea733fc6273c76bed910f
prerequisite-patch-id: a328539ba621866e4a63b39ab72a54dbfb3ed0a1
prerequisite-patch-id: 991f843051a913188e0cb671f3e8768682f895e5
prerequisite-patch-id: c05688baf37b3e80a57fe85d351f997f017acea2
prerequisite-patch-id: 36038f3f55748416fe56dc990d3836f70e851f59
--
Sincerely yours,
Mike.
next reply other threads:[~2026-09-03 15:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 15:49 Mike Rapoport (Microsoft) [this message]
2026-09-03 15:49 ` [PATCH 1/5] mm/execmem: free ROX cache chunks only when they span an entire vm area Mike Rapoport (Microsoft)
2026-09-03 15:49 ` [PATCH 2/5] mm/execmem: handle potential allocation errors in the maple tree Mike Rapoport (Microsoft)
2026-09-03 15:50 ` [PATCH 3/5] mm/execmem: make sure ROX cache always contains multiples of PMD_SIZE Mike Rapoport (Microsoft)
2026-09-03 15:50 ` [PATCH 4/5] mm/vmalloc: add DEFINE_FREE() for vfree() Mike Rapoport (Microsoft)
2026-09-03 15:50 ` [PATCH 5/5] mm/execmem: use cleanup infrastructure in ROX cache functions Mike Rapoport (Microsoft)
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=20260903-execmem-rox-cache-pmd-v1-v1-0-11beb2a3d249@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bentiss@kernel.org \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mcgrof@kernel.org \
--cc=stable@vger.kernel.org \
--cc=urezki@gmail.com \
/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 NNTP newsgroup(s).