On Wed, 24 Jun 2026 at 02:11, Long Li [off-list ref] wrote:

quoted

The EAL hotplug multi-process messaging uses a fixed-size buffer
(EAL_DEV_MP_DEV_ARGS_MAX_LEN, 128 bytes) for device arguments.
When devargs exceeds this limit, strlcpy silently truncates the
string. This causes secondary processes to receive incomplete devargs
during hotplug re-add, leading to failed port re-initialization.

For example, a MANA PCI device with 6 mac= arguments:

  mac=AA:BB:CC:DD:EE:01,mac=AA:BB:CC:DD:EE:02,
  mac=AA:BB:CC:DD:EE:03,mac=AA:BB:CC:DD:EE:04,
  mac=AA:BB:CC:DD:EE:05,mac=AA:BB:CC:DD:EE:06

produces a 131-byte devargs string that gets silently truncated to 127
bytes, losing the last MAC address.

Return -E2BIG from rte_dev_probe() when devargs would be truncated,
instead of silently corrupting data. rte_dev_remove() does not need
the same check because the length was already validated at probe time.

Fixes: 244d5130719c ("eal: enable hotplug on multi-process")
Cc: stable@dpdk.org

Signed-off-by: Long Li <longli@microsoft.com>

Re-reading the function, I have one concern about the fix.

I agree there is a bug with multiprocess.
But this change here also imposes a limit to 128 that was not there before,
even if multiprocess is disabled.
It may not be a big problem, but we are calling the the multi process
machinerie when unneeded (it ends up with a ENOTSUP).

I sent a small patch on this topic, could you have a look please?

Thank you. I sent a review comment. This patch looks good.

I'll modify this patch to have the length check inside if (do_mp) block.

Long

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Finbox.
dpdk.org%2Fdev%2F20260625072254.4190227-1-
david.marchand%40redhat.com%2F&data=05%7C02%7Clongli%40microsoft.c
om%7Cf1cf337c1f014cc8b83b08ded28ab9d4%7C72f988bf86f141af91ab2d7cd
011db47%7C1%7C0%7C639179690431011725%7CUnknown%7CTWFpbGZsb3
d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI
joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7otoCpQbXZvcj5tSD
QAJ77sdfu8U%2BgPwZZyYeTC%2F2lw%3D&reserved=0


--
David Marchand