[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210830235927.6443-9-rick.p.edgecombe@intel.com>
Date: Mon, 30 Aug 2021 16:59:16 -0700
From: Rick Edgecombe <rick.p.edgecombe@...el.com>
To: dave.hansen@...el.com,
luto@...nel.org,
peterz@...radead.org,
x86@...nel.org,
akpm@...ux-foundation.org,
keescook@...omium.org,
shakeelb@...gle.com,
vbabka@...e.cz,
rppt@...nel.org
Cc: Rick Edgecombe <rick.p.edgecombe@...el.com>,
linux-mm@...ck.org,
linux-hardening@...r.kernel.org,
kernel-hardening@...ts.openwall.com,
ira.weiny@...el.com,
dan.j.williams@...el.com,
linux-kernel@...r.kernel.org
Subject: [RFC PATCH v2 08/19] x86/mm/cpa: Add get_grouped_page_atomic()
For PKS tables, some page table allocations are made with GFP_ATOMIC,
which up to now has not been supported.
Grouped pages may often have pages in the cache, which can be retrieved
without sleeping, however if the cache is empty, it will need try to
replenish from the normal page allocator. Just passing GFP_ATOMIC in
addition to the configure GFP is not ideal because it may try to grab a
whole huge page size page which will stress the atomic reserves.
So instead create new logic that will only try to allocate a single page
and convert it.
Expose this atomic logic in a new function get_grouped_page_atomic(),
instead of allowing a flag to be passed in. This is so it doesn't look
like any GFP flag can get passed in and result in behavior like normal
allocations.
In the case of PKS tables conversion of the page allocated atomically,
set_memory() calls cannot usually be made in atomic context because
pages may need to be allocated, but PKS tables has its own reserve of
direct map tables so pages can be converted to PKS protected in atomic
context.
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@...el.com>
---
arch/x86/include/asm/set_memory.h | 1 +
arch/x86/mm/pat/set_memory.c | 26 ++++++++++++++++++++++++++
2 files changed, 27 insertions(+)
diff --git a/arch/x86/include/asm/set_memory.h b/arch/x86/include/asm/set_memory.h
index eaac7e3e08bf..e0516651698a 100644
--- a/arch/x86/include/asm/set_memory.h
+++ b/arch/x86/include/asm/set_memory.h
@@ -153,6 +153,7 @@ int init_grouped_page_cache(struct grouped_page_cache *gpc, gfp_t gfp,
gpc_callback pre_add_to_cache,
gpc_callback pre_shrink_free);
struct page *get_grouped_page(int node, struct grouped_page_cache *gpc);
+struct page *get_grouped_page_atomic(int node, struct grouped_page_cache *gpc);
void free_grouped_page(struct grouped_page_cache *gpc, struct page *page);
#endif /* _ASM_X86_SET_MEMORY_H */
diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
index 72a465e37648..c51792a797cb 100644
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@ -2496,6 +2496,32 @@ struct page *get_grouped_page(int node, struct grouped_page_cache *gpc)
return __replenish_grouped_pages(gpc, node);
}
+struct page *get_grouped_page_atomic(int node, struct grouped_page_cache *gpc)
+{
+ struct page *page;
+
+ if (in_interrupt()) {
+ pr_warn_once("grouped pages: Cannot allocate grouped page in interrupt");
+ return NULL;
+ }
+
+ /* First see if there are any grouped pages already in the cache */
+ page = __remove_first_page(gpc, node);
+
+ /*
+ * If there wasn't one in the cache, allocate only a single page to not
+ * stress the reserves.
+ */
+ if (!page)
+ page = __alloc_page_order(node, gpc->gfp | GFP_ATOMIC, 0);
+
+ /* Convert the single page if configured for this cache */
+ if (!page || __try_convert(gpc, page, 1))
+ return NULL;
+
+ return page;
+}
+
void free_grouped_page(struct grouped_page_cache *gpc, struct page *page)
{
INIT_LIST_HEAD(&page->lru);
--
2.17.1
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
