Re: [PATCH net-next 00/14] ipmr, ip6mr: Allow MC-routing locally-generated MC packets

Petr Machata [off-list ref] writes:

Jakub Kicinski [off-list ref] writes:

quoted

On Mon, 9 Jun 2025 22:50:16 +0200 Petr Machata wrote:

quoted

Multicast routing is today handled in the input path. Locally generated MC
packets don't hit the IPMR code. Thus if a VXLAN remote address is
multicast, the driver needs to set an OIF during route lookup. In practice
that means that MC routing configuration needs to be kept in sync with the
VXLAN FDB and MDB. Ideally, the VXLAN packets would be routed by the MC
routing code instead.

I think this leads to kmemleaks:
[...]
hit by netdevsim udp_tunnel_nic.sh

Thanks, I'll take a look.

Hmm, I can't reproduce this :-| I'm using the following incantation to
build the kernel:

    vng --build --config tools/testing/selftests/net/forwarding/config \
                --config tools/testing/selftests/drivers/net/config \
                --config tools/testing/selftests/drivers/net/netdevsim/config \
                --config kernel/configs/debug.config

And run the test like so:

    vng -v --run . --user root --cpus 4 -- \
        make -C tools/testing/selftests TARGETS=drivers/net/netdevsim \
                TEST_PROGS=udp_tunnel_nic.sh TEST_GEN_PROGS="" run_tests

vng -v --run . --user root --cpus 4 -- \
        bash -c 'make -C tools/testing/selftests TARGETS=drivers/net/netdevsim \
                        TEST_PROGS=udp_tunnel_nic.sh TEST_GEN_PROGS="" run_tests; \
                 echo scan > /sys/kernel/debug/kmemleak; \
                 cat /sys/kernel/debug/kmemleak'

Anything I'm missing, or is this what the CI is doing, more or less?

Could it actually have been caused by another test? The howto page
mentions that the CI is running the tests one at a time, so I don't
suppose that's a possibility.

I'll try to run a more fuller suite tomorrow and star at the code a bit
to see if I might be missing an error branch or something.