All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Lau <kafai@fb.com>
To: David Ahern <dsahern@gmail.com>
Cc: Wei Wang <weiwan@google.com>, David Ahern <dsahern@kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>,
	"idosch@mellanox.com" <idosch@mellanox.com>,
	"saeedm@mellanox.com" <saeedm@mellanox.com>
Subject: Re: [PATCH v2 net-next 4/7] ipv6: Plumb support for nexthop object in a fib6_info
Date: Tue, 4 Jun 2019 05:29:32 +0000	[thread overview]
Message-ID: <20190604052929.4mlxa5sswm46mwrq@kafai-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <453565b0-d08a-be96-3cd7-5608d4c21541@gmail.com>

On Mon, Jun 03, 2019 at 07:36:06PM -0600, David Ahern wrote:
> On 6/3/19 6:58 PM, Martin Lau wrote:
> > I have concern on calling ip6_create_rt_rcu() in general which seems
> > to trace back to this commit
> > dec9b0e295f6 ("net/ipv6: Add rt6_info create function for ip6_pol_route_lookup")
> > 
> > This rt is not tracked in pcpu_rt, rt6_uncached_list or exception bucket.
> > In particular, how to react to NETDEV_UNREGISTER/DOWN like
> > the rt6_uncached_list_flush_dev() does and calls dev_put()?
> > 
> > The existing callers seem to do dst_release() immediately without
> > caching it, but still concerning.
> 
> those are the callers that don't care about the dst_entry, but are
> forced to deal with it. Removing the tie between fib lookups an
> dst_entry is again the right solution.
Great to know that there will be a solution.  It would be great
if there is patch (or repo) to show how that may look like on
those rt6_lookup() callers.

Before that,
although it seems fine now (__ip6_route_redirect() is
harder to confirm since rt is passed around but it
seems to be ok),
instead of risking for "unregister_netdevice: waiting for eth0 to become free"
in case some future patch is caching this rt,
why pcpu_rt cannot be used in all occasions? and also
avoid re-creating the same rt.

  reply	other threads:[~2019-06-04  5:29 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-03  4:08 [PATCH v2 net-next 0/7] net: add struct nexthop to fib{6}_info David Ahern
2019-06-03  4:08 ` [PATCH v2 net-next 1/7] ipv4: Use accessors for fib_info nexthop data David Ahern
2019-06-03  4:08 ` [PATCH v2 net-next 2/7] ipv4: Prepare for fib6_nh from a nexthop object David Ahern
2019-06-03  4:08 ` [PATCH v2 net-next 3/7] ipv4: Plumb support for nexthop object in a fib_info David Ahern
2019-06-03  4:08 ` [PATCH v2 net-next 4/7] ipv6: Plumb support for nexthop object in a fib6_info David Ahern
2019-06-03 18:09   ` Wei Wang
2019-06-03 18:37     ` David Ahern
2019-06-03 20:42     ` David Ahern
2019-06-03 21:58       ` Wei Wang
2019-06-03 22:35         ` David Ahern
2019-06-03 23:05           ` Wei Wang
2019-06-03 23:18             ` David Ahern
2019-06-03 23:30               ` Wei Wang
2019-06-04  0:58               ` Martin Lau
2019-06-04  1:36                 ` David Ahern
2019-06-04  5:29                   ` Martin Lau [this message]
2019-06-04 20:17                     ` David Ahern
2019-06-04 21:06                       ` Martin Lau
2019-06-04 21:13                         ` David Ahern
2019-06-04 21:36                           ` Wei Wang
2019-06-04 23:30                             ` David Ahern
2019-06-05  0:39                             ` Martin Lau
2019-06-05  2:05                               ` David Ahern
2019-06-05  6:01                                 ` Martin Lau
2019-06-04 21:53                           ` Martin Lau
2019-06-03  4:08 ` [PATCH v2 net-next 5/7] mlxsw: Fail attempts to use routes with nexthop objects David Ahern
2019-06-03  4:08 ` [PATCH v2 net-next 6/7] mlx5: " David Ahern
2019-06-03  4:08 ` [PATCH v2 net-next 7/7] rocker: " David Ahern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190604052929.4mlxa5sswm46mwrq@kafai-mbp.dhcp.thefacebook.com \
    --to=kafai@fb.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=dsahern@kernel.org \
    --cc=idosch@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@mellanox.com \
    --cc=weiwan@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.