Error with --no-huge when compiled with -fsanitize=address from gcc 15

[Robin Jarry]

Hi Anatoly,

Burakov, Anatoly, Sep 05, 2025 at 11:17:
> Specifically, it's weird that your DMA width is 42 bits (indicated by 
> "using dma mask fffffc0000000000" log), running on a physical machine - 
> mine sits at 57 bits, so despite having VA's within the same range as 
> yours, this works on my machine because my DMA mask is much wider. Maybe 
> there's a kernel command-line of some sort that limits your DMA width?
>
> At first glance I don't think the issue has anything to do with DPDK, at 
> least it doesn't look like it does to me. I do not see how DMA mask 
> width would be affected by libasan or GCC15, to me it sounds more like a 
> kernel configuration/HW setup problem.

NB: The problem *only* appears when I compile with -fsanitize=address.
Hence my suspicion around GCC/libasan. There must be something done by
ASAN that changes the address space.

Digging further with your advice (and some help from AI...), I found
that the DMA width (42 bits) as reported by EAL debug logs actually come
from my laptop having a new "security feature" enabled in the BIOS:

	Kernel DMA Protection

When this "feature" is enabled, IOMMU is forced-on during early boot:

	DMAR: Intel-IOMMU force enabled due to platform opt in

Also, my IOMMU exposes a limited DMA width (I don't know why). My CPU
model is:

	Intel(R) Core(TM) Ultra 7 165U

I have disabled DMA protection in the BIOS, and the problem is now gone.

Interestingly, whenever I explicitly enable IOMMU in the kernel boot
arguments (iommu=pt intel_iommu=on), the issue manifests itself again.
This is therefore a weird interaction between ASAN, the IOMMU on my
laptop and DPDK memory initialization.

Anyway, sorry for the noise. Maybe, my experience may be useful to
others :)

Thanks for your assistance!

-- 
Robin

> Will stain.