DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Robin Jarry <rjarry@redhat.com>, <dev@dpdk.org>
Subject: Re: Error with --no-huge when compiled with -fsanitize=address from gcc 15
Date: Thu, 18 Sep 2025 11:01:41 +0200	[thread overview]
Message-ID: <7cc3b042-7603-4bc5-ac3d-1c6b37d38c1d@intel.com> (raw)
In-Reply-To: <DCOK6VADCGM4.147AQDN77QTJO@redhat.com>

On 9/9/2025 10:40 PM, Robin Jarry wrote:
> 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.
>

Hi Robin,

ASAN wouldn't interfere with address space itself but it will cause the 
addresses to go higher (the default starting address is such that it 
should fit within even smaller DMA masks so normally this isn't an 
issue) because of shadowing, so while ASAN itself doesn't affect the DMA 
mask, it will affect the addresses you get.


> 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.

This is interesting. I've never dealt with running DPDK on a laptop, 
maybe the limited DMA width is endemic to laptops or something.

> 
> 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!
> 

No problem!

-- 
Thanks,
Anatoly

      reply	other threads:[~2025-09-18  9:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-15 10:32 Robin Jarry
2025-06-10  8:15 ` Robin Jarry
2025-09-04 14:35   ` Burakov, Anatoly
2025-09-04 14:49     ` Robin Jarry
2025-09-05  9:17       ` Burakov, Anatoly
2025-09-09 20:40         ` Robin Jarry
2025-09-18  9:01           ` Burakov, Anatoly [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7cc3b042-7603-4bc5-ac3d-1c6b37d38c1d@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=rjarry@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).