On Wed, Jul 22, 2015 at 11:10:59AM +0900, YOSHIFUJI Hideaki wrote:
You have to take some lock when accessing neigh-nud_state
theoretically.
I don't think read_lock can buy us a lot of extra protection either.
If it has missed the train, the next ip6_pol_route() call will
trigger rt6_probe().
Hi,
Martin KaFai Lau wrote:
The patch checks neigh-nud_state before acquiring the writer lock.
Note that rt6_probe() is only used in CONFIG_IPV6_ROUTER_PREF.
You have to take some lock when accessing neigh-nud_state
theoretically.
I also take this chance to re-arrange the code.
No, please
Hello,
On Tue, 21 Jul 2015, Martin KaFai Lau wrote:
The patch checks neigh-nud_state before acquiring the writer lock.
Note that rt6_probe() is only used in CONFIG_IPV6_ROUTER_PREF.
Locking usage is absolutely correct.
+ if (!(neigh-nud_state NUD_VALID)
+
The patch checks neigh-nud_state before acquiring the writer lock.
Note that rt6_probe() is only used in CONFIG_IPV6_ROUTER_PREF.
I also take this chance to re-arrange the code.
40 udpflood processes and a /64 gateway route are used.
The gateway has NUD_PERMANENT. Each of them is run for 30s.
