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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87o6uui6f7.fsf@nvidia.com>
Date: Wed, 11 Jun 2025 17:30:15 +0200
From: Petr Machata <petrm@...dia.com>
To: Petr Machata <petrm@...dia.com>
CC: Jakub Kicinski <kuba@...nel.org>, "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, "David
 Ahern" <dsahern@...il.com>, <netdev@...r.kernel.org>, Simon Horman
	<horms@...nel.org>, Nikolay Aleksandrov <razor@...ckwall.org>, Ido Schimmel
	<idosch@...dia.com>, <mlxsw@...dia.com>
Subject: Re: [PATCH net-next 00/14] ipmr, ip6mr: Allow MC-routing
 locally-generated MC packets


Petr Machata <petrm@...dia.com> writes:

> Jakub Kicinski <kuba@...nel.org> writes:
>
>> On Mon, 9 Jun 2025 22:50:16 +0200 Petr Machata wrote:
>>> 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.