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: <Ya6kJhUtJt5c8tEk@lunn.ch>
Date:   Tue, 7 Dec 2021 01:00:38 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Eric Dumazet <edumazet@...gle.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>,
        Dmitry Vyukov <dvyukov@...gle.com>
Subject: Re: [PATCH v3 net-next 00/23] net: add preliminary netdev refcount
 tracking

On Mon, Dec 06, 2021 at 03:44:57PM -0800, Eric Dumazet wrote:
> On Mon, Dec 6, 2021 at 3:24 PM Andrew Lunn <andrew@...n.ch> wrote:
> >
> > On Sat, Dec 04, 2021 at 08:21:54PM -0800, Eric Dumazet wrote:
> > > From: Eric Dumazet <edumazet@...gle.com>
> > >
> > > Two first patches add a generic infrastructure, that will be used
> > > to get tracking of refcount increments/decrements.
> >
> > Hi Eric
> >
> > Using this i found:
> >
> > [  774.108901] unregister_netdevice: waiting for eth0 to become free. Usage count = 4
> > [  774.110864] leaked reference.
> > [  774.110874]  dst_alloc+0x7a/0x180
> > [  774.110887]  ip6_dst_alloc+0x27/0x90
> > [  774.110894]  ip6_pol_route+0x257/0x430
> > [  774.110900]  ip6_pol_route_output+0x19/0x20
> > [  774.110905]  fib6_rule_lookup+0x18b/0x270
> > [  774.110914]  ip6_route_output_flags_noref+0xaa/0x110
> > [  774.110918]  ip6_route_output_flags+0x32/0xa0
> > [  774.110922]  ip6_dst_lookup_tail.constprop.0+0x181/0x240
> > [  774.110929]  ip6_dst_lookup_flow+0x43/0xa0
> > [  774.110934]  inet6_csk_route_socket+0x166/0x200
> > [  774.110943]  inet6_csk_xmit+0x56/0x130
> > [  774.110946]  __tcp_transmit_skb+0x53b/0xc30
> > [  774.110953]  __tcp_send_ack.part.0+0xc6/0x1a0
> > [  774.110958]  tcp_send_ack+0x1c/0x20
> > [  774.110964]  __tcp_ack_snd_check+0x42/0x200
> > [  774.110968]  tcp_rcv_established+0x27a/0x6f0
> > [  774.110973] leaked reference.
> > [  774.110975]  ipv6_add_dev+0x13e/0x4f0
> > [  774.110982]  addrconf_notify+0x2ca/0x950
> > [  774.110989]  raw_notifier_call_chain+0x49/0x60
> > [  774.111000]  call_netdevice_notifiers_info+0x50/0x90
> > [  774.111007]  __dev_change_net_namespace+0x30d/0x6c0
> > [  774.111016]  do_setlink+0xdc/0x10b0
> > [  774.111024]  __rtnl_newlink+0x608/0xa10
> > [  774.111031]  rtnl_newlink+0x49/0x70
> > [  774.111038]  rtnetlink_rcv_msg+0x14f/0x380
> > [  774.111046]  netlink_rcv_skb+0x55/0x100
> > [  774.111053]  rtnetlink_rcv+0x15/0x20
> > [  774.111059]  netlink_unicast+0x230/0x340
> > [  774.111064]  netlink_sendmsg+0x252/0x4b0
> > [  774.111075]  sock_sendmsg+0x65/0x70
> > [  774.111080]  ____sys_sendmsg+0x24e/0x290
> > [  774.111084]  ___sys_sendmsg+0x81/0xc0
> >
> > I'm using GNS3 to simulate a network topology. So a collection of veth
> > pairs, bridges and tap interfaces spread over a few namespaces. The
> > network being simulated uses Segment Routing. And traceroute might also
> > involved in this somehow. I have 3 patches applied, to make traceroute
> > actually work when SRv6 is being used. You can find v3 here:
> >
> > https://lore.kernel.org/netdev/20211203162926.3680281-3-andrew@lunn.ch/T/
> >
> > I'm not sure if these patches are part of the problem or not. None of
> > the traces i've seen are directly on the ICMP path. traceroute is
> > using udp, and one of the traces above is for tcp, and the other looks
> > like it is moving an interface into a different namespace?
> >
> > This is net-next from today.
> 
> I do not understand, net-next does not contain this stuff yet ?

Hi Eric

I'm getting warnings like:

unregister_netdevice: waiting for eth0 to become free. Usage count = 4

which is what your patchset is supposed to help fix. So i applied what
has been posted so far, in the hope it would find the issue. It is
reporting something...

> I have other patches, this work is still in progress.

Is what is currently posted usable? Do these traces above point at the
real problem i have, or because there are more patches, i should not
trust the output?

      Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ