netdev - Re: [PATCH v2 net-next 4/7] ipv6: Plumb support for nexthop object in a fib6

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: <a5838766-529c-75dd-5793-3abe4e56ed1c@gmail.com>
Date:   Tue, 4 Jun 2019 20:05:58 -0600
From:   David Ahern <dsahern@...il.com>
To:     Martin Lau <kafai@...com>, Wei Wang <weiwan@...gle.com>
Cc:     David Ahern <dsahern@...nel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        "idosch@...lanox.com" <idosch@...lanox.com>,
        "saeedm@...lanox.com" <saeedm@...lanox.com>
Subject: Re: [PATCH v2 net-next 4/7] ipv6: Plumb support for nexthop object in
 a fib6_info

On 6/4/19 6:39 PM, Martin Lau wrote:
> IMO, ip6_create_rt_rcu(), which returns untracked rt, was a mistake
> and removing it has been overdue.  Tracking down the unregister dev
> bug is not easy.

I must be missing something because I don't have the foggiest idea why
you are barking up this tree.

If code calls a function that returns a dst_entry with a refcount taken,
that code is responsible for releasing it. Using a pcpu cached dst
versus a new one in no way tells you who took the dst and bumped the
refcnt on the netdev. Either way the dst refcount is bumped. Tracking
netdev refcnt is the only way to methodically figure it out.

What am I overlooking here?