netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* ip6_rt_gc_elasticity and ip6_rt_gc_min_interval race in rt6_alloc_cow() ?
@ 2012-11-30 18:43 Jiri Bohac
  2012-11-30 18:50 ` David Miller
  0 siblings, 1 reply; 2+ messages in thread
From: Jiri Bohac @ 2012-11-30 18:43 UTC (permalink / raw)
  To: netdev; +Cc: mkubecek

Hi,

I came across this code in rt6_alloc_cow():


	if (rt6_bind_neighbour(rt, rt->dst.dev)) {
		struct net *net = dev_net(rt->dst.dev);
		int saved_rt_min_interval =
			net->ipv6.sysctl.ip6_rt_gc_min_interval;
		int saved_rt_elasticity =
			net->ipv6.sysctl.ip6_rt_gc_elasticity;

		if (attempts-- > 0) {
			net->ipv6.sysctl.ip6_rt_gc_elasticity = 1;
			net->ipv6.sysctl.ip6_rt_gc_min_interval = 0;

			ip6_dst_gc(&net->ipv6.ip6_dst_ops);

			net->ipv6.sysctl.ip6_rt_gc_elasticity =
				saved_rt_elasticity;
			net->ipv6.sysctl.ip6_rt_gc_min_interval =
				saved_rt_min_interval;
			goto retry;
		}

		net_warn_ratelimited("Neighbour table overflow\n");
		dst_free(&rt->dst);
		return NULL;
	}

I believe there is a race condition in the setting of
ip6_rt_gc_elasticity and ip6_rt_gc_min_interval. I have not seen
happen, though:

1) a setting made by the user via sysctl while ip6_dst_gc() is
   running will get lost

2) another instance of rt6_alloc_cow() may save the temporary
   values in the saved_* variables, making those permanent.

Am I overlooking some synchronization or should I send a
patch to fix this?


Thanks,


-- 
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: ip6_rt_gc_elasticity and ip6_rt_gc_min_interval race in rt6_alloc_cow() ?
  2012-11-30 18:43 ip6_rt_gc_elasticity and ip6_rt_gc_min_interval race in rt6_alloc_cow() ? Jiri Bohac
@ 2012-11-30 18:50 ` David Miller
  0 siblings, 0 replies; 2+ messages in thread
From: David Miller @ 2012-11-30 18:50 UTC (permalink / raw)
  To: jbohac; +Cc: netdev, mkubecek

From: Jiri Bohac <jbohac@suse.cz>
Date: Fri, 30 Nov 2012 19:43:36 +0100

> I believe there is a race condition in the setting of
> ip6_rt_gc_elasticity and ip6_rt_gc_min_interval. I have not seen
> happen, though:
> 
> 1) a setting made by the user via sysctl while ip6_dst_gc() is
>    running will get lost
> 
> 2) another instance of rt6_alloc_cow() may save the temporary
>    values in the saved_* variables, making those permanent.
> 
> Am I overlooking some synchronization or should I send a
> patch to fix this?

The ipv4 routing cache had the same issue, I really and sincerely
doubt this race matters in practice.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-11-30 18:50 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-30 18:43 ip6_rt_gc_elasticity and ip6_rt_gc_min_interval race in rt6_alloc_cow() ? Jiri Bohac
2012-11-30 18:50 ` David Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).