NACK/CMT: [SRU][B/F][PATCH v2 0/1] vrf: fix refcnt leak with vxlan slaves
Kelsey Skunberg
kelsey.skunberg at canonical.com
Tue Oct 5 22:30:27 UTC 2021
Hey Luke - Sorry to nack v2 on you, though both patches are missing the BugLink.
May you please add those and re-send?
-Kelsey
On 2021-10-05 11:35:15 , Luke Nowakowski-Krijger wrote:
> This is a backport request by Nicolas Dichtel <nicolas.dichtel at 6wind.com>
>
> BugLink: https://bugs.launchpad.net/bugs/1945180
>
> [Impact]
>
> There are cases, where deleting a VRF device can hang waiting for the refcnt
> to drop to 0, with the message:
> unregister_netdevice: waiting for vrf1 to become free. Usage count = 1
>
> This is fixed upstream with commit b87b04f5019e
> ("ipv4: Fix device used for dst_alloc with local routes"), included in linux
> v5.13. The original patch, which has introduced the bug, is included in
> linux v4.10.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b87b04f5019e
>
> [Backports for Bionic]
>
> Removed updates to tools/testing/selftests/net/fib_tests.sh as they do not
> exist for bionic. Also changed the struct referenced in the patch from
> fib_nh_common to fib_nh as well as the associated accesses to the
> struct.
>
> [Test Case]
>
> Reproduced the bug with the upstream test case which also is the test in
> the original patch added to fib_tests.sh.
> Confirmed that after the patch was applied the test case does not hang
> and successfully removes VRF device.
>
> [Regression Potential]
>
> Relatively straightforward in that it links a new dst to a vrf device
> isntead of the loopback if there is a valid nexthop device.
>
> David Ahern (1):
> ipv4: Fix device used for dst_alloc with local routes
>
> net/ipv4/route.c | 16 ++++++++++++++-
> tools/testing/selftests/net/fib_tests.sh | 25 ++++++++++++++++++++++++
> 2 files changed, 40 insertions(+), 1 deletion(-)
>
> --
> 2.30.2
>
>
> --
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team
More information about the kernel-team
mailing list