On Tue, Jun 11, 2013 at 01:01:14PM -0700, David Miller wrote:

From: Michal Kubecek <redacted>
Date: Tue, 11 Jun 2013 12:07:18 +0200

quoted

On Mon, Jun 10, 2013 at 02:26:42PM -0700, David Miller wrote:

quoted

It seems to me that it would be much simpler to simply update
ip6_rt_last_gc first, that way the other threads would elide the GC
call.

That was my original idea but I was afraid that while the remaining
window in ip6_dst_gc() would be very short and probably safe, we could
still run into problem if fib6_gc_lock was locked by some other caller
of fib6_run_gc() which doesn't update net->ipv6.ip6_rt_last_gc,
especially via a timer.

Why don't you simply try it and find out?

I don't have the system where the issue was observed at hand. I'll have
to ask the customer who reported it to run the test so that it may take
some time.

                                                         Michal Kubecek