Re: [PATCH v9 04/11] x86/virt/tdx: Allocate refcounts for Dynamic PAMT memory

[Edgecombe, Rick P]

CC everyone on this Sashiko comment, because I think its not 100% clear cut how
to handle it.

On Thu, 2026-08-06 at 02:21 +0000, sashiko-bot@xxxxxxxxxx wrote:
> [Severity: High]
> Could this vzalloc() call trigger a kernel panic on systems with sparse
> memory layouts instead of gracefully disabling TDX?
> 
> The allocation size based on max_pfn can be extremely large (up to 8GB).
> Because vzalloc() does not include __GFP_RETRY_MAYFAIL, an allocation
> failure will invoke the page allocator slow path and the OOM killer. Since
> this runs during early boot before any killable user processes exist, the
> OOM killer will unconditionally call panic() instead of returning NULL.
> 
> Would it be safer to use __vmalloc() with GFP_KERNEL | __GFP_ZERO |
> __GFP_RETRY_MAYFAIL | __GFP_NOWARN to ensure the allocator returns NULL
> when memory is exhausted?

I think this is a bit overblown. If there is a lot of memory such that this
allocation is large, we can expect it be less likely to fail.

So I'm not sure it needs special handling. The tradeoff is more non-standard
code to read and consider, weighed against what I think is probably a low cost
of hitting the problem. So I think I'll leave it. Especially since DPAMT is an
opt-in, there is an escape hatch for now. So if the reasoning is very wrong,
impact is not horrible.