On Fri, 26 Jun 2026 at 20:20, Long Li <[email protected]> wrote: > > > > > On Wed, 24 Jun 2026 at 02:11, Long Li <[email protected]> wrote: > > > > > > 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: [email protected] > > > > > > Signed-off-by: Long Li <[email protected]> > > > > 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.
I did it directly. With this adjustment: Acked-by: David Marchand <[email protected]> -- David Marchand
