Jason Gunthorpe <[email protected]> writes:
> On Thu, Sep 24, 2026 at 07:52:39PM +0530, Aneesh Kumar K.V wrote:
[ ... 67 lines skipped ... ]
>
>> >> + if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
>> >> + return __alloc_cc_shared_pages_node(nid, gfp, requested, mem);
>> >> +
>> >> + order = get_order(requested);
>> >> + if (order > MAX_PAGE_ORDER)
>> >> + return -EINVAL;
>> >> +
>> >> + if (nid == NUMA_NO_NODE)
>> >> + page = alloc_pages(gfp, order);
>> >> + else
>> >> + page = alloc_pages_node(nid, gfp, order);
>> >
>> > [Severity: Medium]
>> > Can this fallback path inadvertently allocate a highmem page?
>> >
>> > The function's kernel-doc explicitly guarantees: "A memory-state transition
>> > requires a valid linear-map address, so such allocations never come from
>> > high memory".
>>
>> Only when a private-to-shared transition is required.
>
> IMHO disable the whole thing at kconfig if highmem is enabled. Make
> the calls always fail.
>
But we also want other kernel subsystems to use alloc_cc_shared_pages()
when CoCo is not enabled. In other words, usage like the following
should work even when the kernel is not running as a CoCo guest.
static struct page *its_alloc_pages_node(int node, gfp_t gfp,
unsigned int order)
{
struct cc_shared_pages mem;
if (alloc_cc_shared_pages_node(node, gfp | gfp_flags_quirk,
PAGE_SIZE << order, &mem))
return NULL;
return mem.page;
}
-aneesh
