[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121130184336.GB7113@midget.suse.cz>
Date: Fri, 30 Nov 2012 19:43:36 +0100
From: Jiri Bohac <jbohac@...e.cz>
To: netdev@...r.kernel.org
Cc: mkubecek@...e.cz
Subject: ip6_rt_gc_elasticity and ip6_rt_gc_min_interval race in
rt6_alloc_cow() ?
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@...e.cz>
SUSE Labs, SUSE CZ
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists