From: Ido Schimmel <idosch@idosch.org>
To: Wei Wang <weiwan@google.com>
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, Jesse Hathaway <jesse@mbuki-mvuki.org>,
Martin KaFai Lau <kafai@fb.com>, David Ahern <dsahern@gmail.com>
Subject: Re: [PATCH net] ipv4: fix race condition between route lookup and invalidation
Date: Thu, 17 Oct 2019 09:24:27 +0300 [thread overview]
Message-ID: <20191017062427.GA25025@splinter> (raw)
In-Reply-To: <20191016190315.151095-1-weiwan@google.com>
On Wed, Oct 16, 2019 at 12:03:15PM -0700, Wei Wang wrote:
> Jesse and Ido reported the following race condition:
> <CPU A, t0> - Received packet A is forwarded and cached dst entry is
> taken from the nexthop ('nhc->nhc_rth_input'). Calls skb_dst_set()
>
> <t1> - Given Jesse has busy routers ("ingesting full BGP routing tables
> from multiple ISPs"), route is added / deleted and rt_cache_flush() is
> called
>
> <CPU B, t2> - Received packet B tries to use the same cached dst entry
> from t0, but rt_cache_valid() is no longer true and it is replaced in
> rt_cache_route() by the newer one. This calls dst_dev_put() on the
> original dst entry which assigns the blackhole netdev to 'dst->dev'
>
> <CPU A, t3> - dst_input(skb) is called on packet A and it is dropped due
> to 'dst->dev' being the blackhole netdev
>
> There are 2 issues in the v4 routing code:
> 1. A per-netns counter is used to do the validation of the route. That
> means whenever a route is changed in the netns, users of all routes in
> the netns needs to redo lookup. v6 has an implementation of only
> updating fn_sernum for routes that are affected.
> 2. When rt_cache_valid() returns false, rt_cache_route() is called to
> throw away the current cache, and create a new one. This seems
> unnecessary because as long as this route does not change, the route
> cache does not need to be recreated.
>
> To fully solve the above 2 issues, it probably needs quite some code
> changes and requires careful testing, and does not suite for net branch.
>
> So this patch only tries to add the deleted cached rt into the uncached
> list, so user could still be able to use it to receive packets until
> it's done.
>
> Fixes: 95c47f9cf5e0 ("ipv4: call dst_dev_put() properly")
> Signed-off-by: Wei Wang <weiwan@google.com>
> Reported-by: Ido Schimmel <idosch@idosch.org>
> Reported-by: Jesse Hathaway <jesse@mbuki-mvuki.org>
> Tested-by: Jesse Hathaway <jesse@mbuki-mvuki.org>
> Acked-by: Martin KaFai Lau <kafai@fb.com>
> Cc: David Ahern <dsahern@gmail.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
next prev parent reply other threads:[~2019-10-17 6:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-16 19:03 [PATCH net] ipv4: fix race condition between route lookup and invalidation Wei Wang
2019-10-17 6:24 ` Ido Schimmel [this message]
2019-10-18 0:01 ` David Miller
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=20191017062427.GA25025@splinter \
--to=idosch@idosch.org \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=jesse@mbuki-mvuki.org \
--cc=kafai@fb.com \
--cc=netdev@vger.kernel.org \
--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.