BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Maciej Fijalkowski" <maciej.fijalkowski@intel.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v3 net-next 14/15] selftests: drv-net: test AF_XDP zero-copy with an SKB peer
Date: Thu, 15 Oct 2026 18:46:43 +0000	[thread overview]
Message-ID: <sashiko-outbox-173334@kernel.org> (raw)
In-Reply-To: <20261014184539.774708-15-maciej.fijalkowski@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] selftests: drv-net: system state leaked on exception in xsk.py
--

commit 800c14b8cb37c2773db542cb20c9fa28d14761b7
Author: Maciej Fijalkowski <maciej.fijalkowski@intel.com>

selftests: drv-net: test AF_XDP zero-copy with an SKB peer

This commit adds a new test script to run AF_XDP zero-copy tests against
an SKB-mode peer using pairs of xskxceiver processes. It sets up ntuple
filters, reserves huge pages, configures queues out of RSS, and cleans up
the configuration when the tests are complete.

> diff --git a/tools/testing/selftests/drivers/net/hw/xsk.py b/tools/testing/selftests/drivers/net/hw/xsk.py
> new file mode 100755
> index 0000000000000..fd708bb3420db
> --- /dev/null
> +++ b/tools/testing/selftests/drivers/net/hw/xsk.py
[ ... ]
> +def _steer_udp(cfg, ifname, port, queue, host=None):
> +    """Steer the test flow to queue, return False if ifname cannot."""
> +    ntuple = ethtool(f"-k {ifname}", json=True, host=host)[0]["ntuple-filters"]
> +    if not ntuple["active"]:
> +        if ntuple["fixed"]:
> +            print(f"1..0 # SKIP {ifname} does not support ntuple-filters")
> +            return False
> +
> +        ethtool(f"-K {ifname} ntuple-filters on", host=host)
> +
> +    out = ethtool(f"-N {ifname} flow-type udp4 dst-port {port} action {queue}",
> +                  host=host).stdout

[Severity: Medium]
If the ethtool command fails here, cmd() will raise a CmdExitFailure
exception since fail=True is the default in net/lib/py. Does this leave
ntuple-filters on permanently enabled on the physical NIC, because the
exception prevents appending the rule to cfg.rules for later cleanup?

> +    rule = re.search(r"ID (\d+)", out).group(1)
> +    cfg.rules.append((host, ifname, rule, ntuple["active"]))
> +    return True
[ ... ]
> +def main():
> +    # ksft_run() exits on -l and -h before main() can undo the setup.
> +    if "-l" in sys.argv or "-h" in sys.argv:
> +        sys.exit(f"{sys.argv[0]}: -l and -h are not supported")
> +
> +    with NetDrvEpEnv(__file__, nsim_test=False) as cfg:
[ ... ]
> +        cases = _get_cases(cfg)
> +
> +        # _fixup_args() sets the options that differ between the cases.
> +        cfg.args = ["--hw",
> +                    "-p", cfg.remote_addr_v["4"],
[ ... ]
> +        cfg.local_args = [str(cfg.bin_local),
> +                          "-i", cfg.ifname,
> +                          "-m", "zc",
> +                          "--queue", str(cfg.queue),
> +                          "--peer-mac", cfg.remote_dev["address"]]
> +
> +        ksft_run([ksft_variants(cases)(test_xsk),
> +                  ksft_variants(cases)(test_xsk_busy_poll)], args=(cfg,))
> +
> +        xsk_release_hugepages(saved_hugepages)
> +        _unsteer_udp(cfg)
> +        ethtool(f"-X {cfg.ifname} default")

[Severity: Medium]
If an exception is raised earlier in main(), such as during _get_cases() or
other setup commands, will execution exit the function immediately and bypass
these cleanup calls?

Since this can leak system-wide configurations like hugepage allocations and
hardware NIC RSS/ntuple settings, would it make sense to protect the cleanup
sequence with a try...finally block?

> +    ksft_exit()
> +
> +
> +if __name__ == "__main__":
> +    main()

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014184539.774708-1-maciej.fijalkowski@intel.com?part=14

  parent reply	other threads:[~2026-10-15 18:46 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14 18:45 [PATCH v3 net-next 00/15] selftests: net: migrate AF_XDP test suite over to net Maciej Fijalkowski
2026-10-14 18:45 ` [PATCH v3 net-next 01/15] selftests: xsk: factor endpoint work out of pthread wrappers Maciej Fijalkowski
2026-10-15  8:14   ` Björn Töpel
2026-10-14 18:45 ` [PATCH v3 net-next 02/15] selftests: xsk: size the TX UMEM in HW_SW_MAX_RING_SIZE Maciej Fijalkowski
2026-10-15  8:15   ` Björn Töpel
2026-10-15 18:46   ` sashiko-bot
2026-10-14 18:45 ` [PATCH v3 net-next 03/15] selftests: xsk: drop the single-interface loopback mode Maciej Fijalkowski
2026-10-15  8:17   ` Björn Töpel
2026-10-14 18:45 ` [PATCH v3 net-next 04/15] selftests/bpf: drop the test_progs AF_XDP wrapper Maciej Fijalkowski
2026-10-15  8:18   ` Björn Töpel
2026-10-14 18:45 ` [PATCH v3 net-next 05/15] selftests: net: add a generic rule for BPF skeletons Maciej Fijalkowski
2026-10-15  8:20   ` Björn Töpel
2026-10-14 18:45 ` [PATCH v3 net-next 06/15] selftests: xsk: move the AF_XDP test suite to selftests/net Maciej Fijalkowski
2026-10-15  8:22   ` Björn Töpel
2026-10-14 18:45 ` [PATCH v3 net-next 07/15] selftests: xsk: collect interface capabilities in struct xsk_caps Maciej Fijalkowski
2026-10-15  8:27   ` Björn Töpel
2026-10-14 18:45 ` [PATCH v3 net-next 08/15] selftests: xsk: split xskxceiver main() into setup, run and cleanup Maciej Fijalkowski
2026-10-15  8:29   ` Björn Töpel
2026-10-14 18:45 ` [PATCH v3 net-next 09/15] selftests: xsk: run one test case per xskxceiver invocation Maciej Fijalkowski
2026-10-15  8:34   ` Björn Töpel
2026-10-15 18:46   ` sashiko-bot
2026-10-14 18:45 ` [PATCH v3 net-next 10/15] selftests: xsk: run the RX and TX endpoints in separate processes Maciej Fijalkowski
2026-10-15  9:04   ` Björn Töpel
2026-10-14 18:45 ` [PATCH v3 net-next 11/15] selftests: xsk: add a hardware mode to xskxceiver Maciej Fijalkowski
2026-10-15  9:42   ` Björn Töpel
2026-10-15 10:55     ` Maciej Fijalkowski
2026-10-15 16:03       ` Björn Töpel
2026-10-14 18:45 ` [PATCH v3 net-next 12/15] selftests: xsk: pass non-test traffic to the stack in hardware mode Maciej Fijalkowski
2026-10-15 10:05   ` Björn Töpel
2026-10-14 18:45 ` [PATCH v3 net-next 13/15] selftests: xsk: list the hardware test cases Maciej Fijalkowski
2026-10-14 18:45 ` [PATCH v3 net-next 14/15] selftests: drv-net: test AF_XDP zero-copy with an SKB peer Maciej Fijalkowski
2026-10-15 10:29   ` Björn Töpel
2026-10-15 12:52     ` Maciej Fijalkowski
2026-10-15 18:46   ` sashiko-bot [this message]
2026-10-14 18:45 ` [PATCH v3 net-next 15/15] selftests: xsk: document generic and hardware endpoint runs Maciej Fijalkowski

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=sashiko-outbox-173334@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=maciej.fijalkowski@intel.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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