On 6/10/2025 10:15 AM, Robin Jarry wrote:
+Anatoly and Ferruh in direct address.
Robin Jarry, May 15, 2025 at 12:32:
I recently updated to Fedora 42 that comes with GCC 15.
When building with -fsanitize=address (libasan.so.8), it seems that
the --no-huge mode (along with --no-shconf) fails at initialization for
some obscure reason.
"couldn't allocate memory due to IOVA exceeding limits of current DMA mask."
Hi Anatoly, Ferruh, all,
Allow me to bump this. GCC 15 has been out for quite a while now and it
seems that libasan cannot be used anymore with the DPDK memory allocator
as it is.
I have tracked the commit that introduced this warning up to 2018:
https://git.dpdk.org/dpdk/commit/?id=165c89b84538f
I would be much grateful if you could help. I don't know the internals
of libasan, but I assume it shuffles mapped memory around and it
conflicts with the DPDK allocator inner workings.
I have found this libasan commit which "could" be related:
https://github.com/llvm/llvm-project/commit/7ede1c497302
In fact, part of it was reverted a while after on macos because of
suspected breakage:
https://github.com/llvm/llvm-project/commit/4e332bba2f3a
Hi Robin,
I have been trying to reproduce this but I'm unable to. I run some old
CentOS so I built GCC15 manually and tried reproducing with that. The
version I'm using is 15.2, could you please retest with latest GCC15 and
see if it was fixed?
(if not, I'll try to get a more recent distro and reproduce again)
The DMA mask checking you're referring to is there for cases where e.g.
in a VM the emulated IOMMU will not have full address width (39 bits was
common at the time), and thus we couldn't use the full VA space for IOVA
addressing, and had to resort to using real physical addresses (because
kernel ensure those are to be within support range of IOMMU). Were you
running this test in a VM, by any chance?
--
Thanks,
Anatoly
