On 10/11/17 3:13 PM, David Miller wrote:
> From: David Ahern <[email protected]>
> Date: Tue, 10 Oct 2017 09:41:02 -0700
>
>> + /* validator notifier needs to be blocking;
>> + * do not call in softirq context
>> + */
>> + if (!in_softirq()) {
>
> I think we can test this better.
The callchain we are protecting against is
7fff8149d0dd ipv6_add_addr ([kernel.kallsyms])
7fff814a161b addrconf_prefix_rcv ([kernel.kallsyms])
7fff814afb8a ndisc_router_discovery ([kernel.kallsyms])
7fff814b0310 ndisc_rcv ([kernel.kallsyms])
7fff814b62da icmpv6_rcv ([kernel.kallsyms])
7fff81499c37 ip6_input_finish ([kernel.kallsyms])
7fff81499e96 ip6_input ([kernel.kallsyms])
7fff8149a519 ip6_mc_input ([kernel.kallsyms])
7fff81499f9d ip6_rcv_finish ([kernel.kallsyms])
7fff8149a349 ipv6_rcv ([kernel.kallsyms])
7fff813fbe12 __netif_receive_skb_core ([kernel.kallsyms])
7fff813fc04c __netif_receive_skb ([kernel.kallsyms])
7fff813ff97c netif_receive_skb_internal ([kernel.kallsyms])
>
> You should be able to audit the call sites and for each one set the
> value of a new boolean argument properly, and this way you can also
> give the boolean argument a descriptive name.
The safest is an in_atomic() check, but to your point I'll see if the
caller can pass in atomic vs blocking option as a bool.
>
> Furthermore, we can also then pull the inet6_addr allocation out of
> the locking paths and thus use GFP_KERNEL when possible.
>
Yes, I was thinking about that as a follow on -- how far down can the
rcu_read_lock_bh be pushed.
