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().
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) &&
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,
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.
A
