From: Hubert Mazur <hmazur@google.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Mike Rapoport <rppt@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Stanislaw Kardach <skardach@google.com>,
Michal Krawczyk <mikrawczyk@google.com>,
Slawomir Rosek <srosek@google.com>,
Lukasz Majczak <lmajczak@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Hubert Mazur <hmazur@google.com>
Subject: [PATCH v2 0/1] Encapsulate the populate and alloc as one atomic
Date: Tue, 17 Mar 2026 12:50:19 +0000 [thread overview]
Message-ID: <20260317125020.1293472-1-hmazur@google.com> (raw)
Hello,
thanks for the review of the v1 patchset. I tried to make v2 diff as
small as possible and without a modification of the core logic.
When a block of memory is requested from the execmem manager the
free_areas tree is traversed to find area of given size. If it is not
found then a new fragment, aligned to a PAGE_SIZE, is allocated and
added to free_areas. Afterwards, the free_areas tree is being traversed
again to fullfil the request.
The above operations of allocation and tree traversal are not atomic
hence another request may consume this newly allocated memory
block dedicated to the original request. As a result - the first
request fails to get the memory. Such occurence can be spotted on
evices running the 6.18 kernel during the paralell modules loading.
Regards
Hubert
Changes in v2:
The __execmem_cache_alloc_locked function (lockless version of
__execmem_cache_alloc) is introduced and called after
execmem_cache_add_locked from the __execmem_cache_populate_alloc
function (renamed from execmem_cache_populate). Both calls are
guarded now with a single mutex.
Changes in v1:
Allocate new memory fragment and assign it directly to the busy_areas
inside execmem_cache_populate function.
Link to v1:
https://lore.kernel.org/all/20260312131438.361746-1-hmazur@google.com/T/#t
Hubert Mazur (1):
mm/execmem: Make the populate and alloc atomic
mm/execmem.c | 61 +++++++++++++++++++++++++++++-----------------------
1 file changed, 34 insertions(+), 27 deletions(-)
--
2.53.0.851.ga537e3e6e9-goog
next reply other threads:[~2026-03-17 12:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-17 12:50 Hubert Mazur [this message]
2026-03-17 12:50 ` [PATCH v2 1/1] mm/execmem: Make the populate and alloc atomic Hubert Mazur
2026-03-18 14:41 ` Mike Rapoport
2026-03-18 14:30 ` [PATCH v2 0/1] Encapsulate the populate and alloc as one atomic Mike Rapoport
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=20260317125020.1293472-1-hmazur@google.com \
--to=hmazur@google.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lmajczak@google.com \
--cc=mikrawczyk@google.com \
--cc=rppt@kernel.org \
--cc=skardach@google.com \
--cc=srosek@google.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