From: David Ahern
Date: Sun, 23 Jun 2019 13:29:27 -0600
> On 6/23/19 12:27 PM, David Miller wrote:
>> From: Wei Wang
>> Date: Thu, 20 Jun 2019 17:36:36 -0700
>>
>>> v2->v3:
>>> - Handled fib6_rule_lookup() when CONFIG_IPV6_MULTIPLE_TABLES is not
>>> configured in patch 03 (suggested by David
On 6/23/19 12:27 PM, David Miller wrote:
> From: Wei Wang
> Date: Thu, 20 Jun 2019 17:36:36 -0700
>
>> v2->v3:
>> - Handled fib6_rule_lookup() when CONFIG_IPV6_MULTIPLE_TABLES is not
>> configured in patch 03 (suggested by David Ahern)
>> - Removed the renaming of l3mdev_link_scope_lookup() in
From: Wei Wang
Date: Thu, 20 Jun 2019 17:36:36 -0700
> v2->v3:
> - Handled fib6_rule_lookup() when CONFIG_IPV6_MULTIPLE_TABLES is not
> configured in patch 03 (suggested by David Ahern)
> - Removed the renaming of l3mdev_link_scope_lookup() in patch 05
> (suggested by David Ahern)
> - Moved d
On Thu, Jun 20, 2019 at 8:50 PM David Ahern wrote:
>
> On 6/20/19 6:36 PM, Wei Wang wrote:
> > From: Wei Wang
> >
> > Ipv6 route lookup code always grabs refcnt on the dst for the caller.
> > But for certain cases, grabbing refcnt is not always necessary if the
> > call path is rcu protected and
On 6/20/19 6:36 PM, Wei Wang wrote:
> From: Wei Wang
>
> Ipv6 route lookup code always grabs refcnt on the dst for the caller.
> But for certain cases, grabbing refcnt is not always necessary if the
> call path is rcu protected and the caller does not cache the dst.
> Another issue in the route l
From: Wei Wang
Ipv6 route lookup code always grabs refcnt on the dst for the caller.
But for certain cases, grabbing refcnt is not always necessary if the
call path is rcu protected and the caller does not cache the dst.
Another issue in the route lookup logic is:
When there are multiple custom r
