2016-04-05 21:28:11

by Bastien Philbert

[permalink] [raw]
Subject: [PATCH] ipv6: icmp: Add protection from concurrent users in the function icmpv6_echo_reply

This adds protection from concurrenct users in the function
icmpv6_echo_reply around the call to the function __in6_dev_get
by locking/unlocking around this call with calls to the functions
rtnl_lock and rtnl_unlock to protect against concurrent users
when calling this function in icmpv6_echo_reply as stated in the
comments for locking requirements for the function, __in6_dev_get.

Signed-off-by: Bastien Philbert <[email protected]>
---
net/ipv6/icmp.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index 0a37ddc..798434f 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -607,7 +607,9 @@ static void icmpv6_echo_reply(struct sk_buff *skb)

hlimit = ip6_sk_dst_hoplimit(np, &fl6, dst);

+ rtnl_lock();
idev = __in6_dev_get(skb->dev);
+ rtnl_unlock();

msg.skb = skb;
msg.offset = 0;
--
2.5.0


2016-04-05 21:36:39

by Hannes Frederic Sowa

[permalink] [raw]
Subject: Re: [PATCH] ipv6: icmp: Add protection from concurrent users in the function icmpv6_echo_reply

On 05.04.2016 23:27, Bastien Philbert wrote:
> This adds protection from concurrenct users in the function
> icmpv6_echo_reply around the call to the function __in6_dev_get
> by locking/unlocking around this call with calls to the functions
> rtnl_lock and rtnl_unlock to protect against concurrent users
> when calling this function in icmpv6_echo_reply as stated in the
> comments for locking requirements for the function, __in6_dev_get.
>
> Signed-off-by: Bastien Philbert <[email protected]>
> ---
> net/ipv6/icmp.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
> index 0a37ddc..798434f 100644
> --- a/net/ipv6/icmp.c
> +++ b/net/ipv6/icmp.c
> @@ -607,7 +607,9 @@ static void icmpv6_echo_reply(struct sk_buff *skb)
>
> hlimit = ip6_sk_dst_hoplimit(np, &fl6, dst);
>
> + rtnl_lock();
> idev = __in6_dev_get(skb->dev);
> + rtnl_unlock();
>
> msg.skb = skb;
> msg.offset = 0;
>

We can't hold rtnl_lock in bh context. Have you seen a rcu verifier
report? I am sure we hold rcu read lock at this point.

Bye,
Hannes