On 19/12/25 11:43, David Hildenbrand (Red Hat) wrote:

On 12/18/25 14:06, Sourabh Jain wrote:

quoted

On 18/12/25 17:32, David Hildenbrand (Red Hat) wrote:

quoted

On 12/18/25 12:41, Sourabh Jain wrote:

quoted

Skip processing hugepage kernel arguments (hugepagesz, hugepages, and
default_hugepagesz) when hugepages are not supported by the
architecture.

Some architectures may need to disable hugepages based on conditions
discovered during kernel boot. The hugepages_supported() helper allows
architecture code to advertise whether hugepages are supported.

Currently, normal hugepage allocation is guarded by
hugepages_supported(), but gigantic hugepages are allocated regardless
of this check. This causes problems on powerpc for fadump (firmware-
assisted dump).

In the fadump (firmware-assisted dump) scenario, a production kernel
crash causes the system to boot into a special kernel whose sole
purpose is to collect the memory dump and reboot. Features such as
hugepages are not required in this environment and should be
disabled.

For example, fadump kernel booting with the kernel arguments
default_hugepagesz=1GB hugepagesz=1GB hugepages=200 prints the
following logs:

HugeTLB: allocating 200 of page size 1.00 GiB failed.  Only allocated
58 hugepages.
HugeTLB support is disabled!
HugeTLB: huge pages not supported, ignoring associated command-line
parameters
hugetlbfs: disabling because there are no supported hugepage sizes

Even though the logs say that hugetlb support is disabled, gigantic
hugepages are still getting allocated, which causes the fadump kernel
to run out of memory during boot.

Yeah, that's suboptimal.

quoted

To fix this, the gigantic hugepage allocation should come under
hugepages_supported().

To bring gigantic hugepage allocation under hugepages_supported(), two
approaches were previously proposed:
[1] Check hugepages_supported() in the generic code before allocating
gigantic hugepages.
[2] Make arch_hugetlb_valid_size() return false for all hugetlb sizes.

Approach [2] has two minor issues:
1. It prints misleading logs about invalid hugepage sizes
2. The kernel still processes hugepage kernel arguments unnecessarily

To control gigantic hugepage allocation, it is proposed to skip
processing the hugepage kernel arguments (hugepagesz, hugepages, and
default_hugepagesz) when hugepages_support() returns false.

You could briefly mention the new output here, so one has a
before-after comparison.

Here is the fadump kernel boot logs after this patch applied:
kernel command had: default_hugepagesz=1GB hugepagesz=1GB hugepages=200

HugeTLB: hugepages unsupported, ignoring default_hugepagesz=1GB cmdline
HugeTLB: hugepages unsupported, ignoring hugepagesz=1GB cmdline
HugeTLB: hugepages unsupported, ignoring hugepages=200 cmdline
HugeTLB support is disabled!
hugetlbfs: disabling because there are no supported hugepage sizes

I will wait for a day or two before sending v2 with the above logs
included in
the commit message.

quoted

Curious, should we at least add a Fixes: tag? Allocating memory when
it's completely unusable sounds wrong.

Not sure which commit I should use for Fixes. This issue has
been present for a long time, possibly since the beginning.

I don't know the full history, but I would assume that support for 
gigantic pages was added later?

It would be great if you could dig a bit so we could add a Fixes:.

The below commit removed the hugepages_supported() call from all three
command-line parsing functions, which inadvertently created an issue
for fadump that my changes attempt to fix.

https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c2833a5bf75b3657c4dd20b3709c8c702754cb1f

I will add fixes tag on above commit and send the next version.

- Sourabh Jain