> Goodness.... where to start. > > If this bug has been around forever, why did you make this patch > against net-next instead of net? (I can tell just by looking at > the patch because rt6_free_pcpu() is static in 'net' yet it is > not static in the diff hunk which matches net-next) > > And if you made it against net-next, why are you saying "net" in > your subject line instead of "[PATCH net-next v2]"? > > Please sort this out properly, and resubmit. > > Thank you.
It should be applied to "net". I will rebase my change and resubmit. Sorry for the confusion. Thanks. Wei On Sun, Aug 20, 2017 at 7:59 PM, David Miller <da...@davemloft.net> wrote: > From: Wei Wang <wei...@google.com> > Date: Sat, 19 Aug 2017 17:34:08 -0700 > >> From: Wei Wang <wei...@google.com> >> >> We currently keep rt->rt6i_node pointing to the fib6_node for the route. >> And some functions make use of this pointer to dereference the fib6_node >> from rt structure, e.g. rt6_check(). However, as there is neither >> refcount nor rcu taken when dereferencing rt->rt6i_node, it could >> potentially cause crashes as rt->rt6i_node could be set to NULL by other >> CPUs when doing a route deletion. >> This patch introduces an rcu grace period before freeing fib6_node and >> makes sure the functions that dereference it takes rcu_read_lock(). >> >> Note: there is no "Fixes" tag because this bug was there in a very >> early stage. >> >> Signed-off-by: Wei Wang <wei...@google.com> >> Acked-by: Eric Dumazet <eduma...@google.com> >> --- >> v2: removed one extra empty line > > Goodness.... where to start. > > If this bug has been around forever, why did you make this patch > against net-next instead of net? (I can tell just by looking at > the patch because rt6_free_pcpu() is static in 'net' yet it is > not static in the diff hunk which matches net-next) > > And if you made it against net-next, why are you saying "net" in > your subject line instead of "[PATCH net-next v2]"? > > Please sort this out properly, and resubmit. > > Thank you.
