[DPDK/ethdev Bug 2092] net/pcap: filename truncation in secondary process

[bugzilla@dpdk.org]

https://bugs.dpdk.org/show_bug.cgi?id=2092

            Bug ID: 2092
           Summary: net/pcap: filename truncation in secondary process
           Product: DPDK
           Version: 26.11
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: ethdev
          Assignee: dev@dpdk.org
          Reporter: stephen@networkplumber.org
  Target Milestone: ---

Summary: net/pcap is truncating silently and breaks secondary
The paths need to be larger and variable length

Longer worded AI version.

Component: drivers/net/pcap
Version: 26.11-rc2 (a13c105)

Description:
The vdev bus multi-process sync passes only the device name to a
secondary, not its arguments. To work around this, the pcap PMD
stores a copy of the devargs string in dev_private, which is
shared with secondaries:

    struct pmd_internals {
        ...
        char devargs[ETH_PCAP_ARG_MAXLEN];   /* 64 */

    strlcpy((*internals)->devargs, rte_vdev_device_args(vdev),
            ETH_PCAP_ARG_MAXLEN);

When a secondary probes, it parses internal->devargs and opens
its own pcap handles from that copy. The limit applies to the
whole argument string, not to each file name, so it is easy to
hit with one long path or with several short arguments.

The primary works normally because it parses the full string.
Only secondaries see the truncated copy, so the problem stays
hidden until something like dpdk-dumpcap, dpdk-pdump or
dpdk-proc-info attaches.

Effects in the secondary:
 - rx_pcap/tx_pcap open fails on the truncated path, so the
   attach fails.
 - Arguments after the cut point (snaplen, infinite_rx, ...)
   are dropped or mis-parsed.
 - If the cut lands on a path that exists, the secondary opens
   the wrong file. For tx_pcap, pcap_dump_open() creates or
   truncates that file.

Steps to reproduce:
 dpdk-testpmd --vdev 'net_pcap0,rx_pcap=<path, devargs 64+ bytes>' \
     -- -i
 dpdk-dumpcap -i net_pcap0 -w /tmp/x.pcapng

Works when the same file is under a short path, e.g. /tmp/a.pcap.

Expected: the secondary sees the same arguments as the primary.
Actual: the secondary probes with a truncated devargs string.

Suggested fix:
Copy the devargs with rte_strdup() so the full string sits in
shared memory, keep a pointer to it in pmd_internals, and free
it on close. Or at least fail the primary probe when the
string will not fit, instead of truncating silently.

-- 
You are receiving this mail because:
You are the assignee for the bug.