[PATCH] ipv6: acquire write lock for addr_list in dev_forward_change

[PATCH] ipv6: acquire write lock for addr_list in dev_forward_change

[Niels Dossche]

No path towards dev_forward_change (common ancestor of paths is in
addrconf_fixup_forwarding) acquires idev->lock for idev->addr_list.
Since addrconf_{join,leave}_anycast acquire a write lock on addr_list in
__ipv6_dev_ac_inc and __ipv6_dev_ac_dec, temporarily unlock when calling
addrconf_{join,leave}_anycast analogous to how it's done in
addrconf_ifdown.

Signed-off-by: Niels Dossche <dossche.niels@gmail.com>
---
 net/ipv6/addrconf.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index f908e2fd30b2..4055ded4b7bf 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -818,14 +818,18 @@ static void dev_forward_change(struct inet6_dev *idev)
 		}
 	}
 
+	write_lock_bh(&idev->lock);
 	list_for_each_entry(ifa, &idev->addr_list, if_list) {
 		if (ifa->flags&IFA_F_TENTATIVE)
 			continue;
+		write_unlock_bh(&idev->lock);
 		if (idev->cnf.forwarding)
 			addrconf_join_anycast(ifa);
 		else
 			addrconf_leave_anycast(ifa);
+		write_lock_bh(&idev->lock);
 	}
+	write_unlock_bh(&idev->lock);
 	inet6_netconf_notify_devconf(dev_net(dev), RTM_NEWNETCONF,
 				     NETCONFA_FORWARDING,
 				     dev->ifindex, &idev->cnf);
-- 
2.35.1

Re: [PATCH] ipv6: acquire write lock for addr_list in dev_forward_change

[Paolo Abeni]

On Wed, 2022-03-16 at 00:02 +0100, Niels Dossche wrote:
> No path towards dev_forward_change (common ancestor of paths is in
> addrconf_fixup_forwarding) acquires idev->lock for idev->addr_list.
> Since addrconf_{join,leave}_anycast acquire a write lock on addr_list in
> __ipv6_dev_ac_inc and __ipv6_dev_ac_dec, temporarily unlock when calling
> addrconf_{join,leave}_anycast analogous to how it's done in
> addrconf_ifdown.
> 
> Signed-off-by: Niels Dossche <dossche.niels@gmail.com>
> ---
>  net/ipv6/addrconf.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index f908e2fd30b2..4055ded4b7bf 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -818,14 +818,18 @@ static void dev_forward_change(struct inet6_dev *idev)
>  		}
>  	}
>  
> +	write_lock_bh(&idev->lock);
>  	list_for_each_entry(ifa, &idev->addr_list, if_list) {
>  		if (ifa->flags&IFA_F_TENTATIVE)
>  			continue;
> +		write_unlock_bh(&idev->lock);

This looks weird?!? if 'addr_list' integrity is guaranteed by 
idev->lock, than this patch looks incorrect. If addr_list integrity is
ensured elsewhere, why acquiring idev->lock at all?

@David: can you please comment here?

Thanks!

Paolo

Re: [PATCH] ipv6: acquire write lock for addr_list in dev_forward_change

[David Ahern]

On 3/17/22 5:13 AM, Paolo Abeni wrote:
> On Wed, 2022-03-16 at 00:02 +0100, Niels Dossche wrote:
>> No path towards dev_forward_change (common ancestor of paths is in
>> addrconf_fixup_forwarding) acquires idev->lock for idev->addr_list.
>> Since addrconf_{join,leave}_anycast acquire a write lock on addr_list in
>> __ipv6_dev_ac_inc and __ipv6_dev_ac_dec, temporarily unlock when calling
>> addrconf_{join,leave}_anycast analogous to how it's done in
>> addrconf_ifdown.
>>
>> Signed-off-by: Niels Dossche <dossche.niels@gmail.com>
>> ---
>>  net/ipv6/addrconf.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>> index f908e2fd30b2..4055ded4b7bf 100644
>> --- a/net/ipv6/addrconf.c
>> +++ b/net/ipv6/addrconf.c
>> @@ -818,14 +818,18 @@ static void dev_forward_change(struct inet6_dev *idev)
>>  		}
>>  	}
>>  
>> +	write_lock_bh(&idev->lock);
>>  	list_for_each_entry(ifa, &idev->addr_list, if_list) {
>>  		if (ifa->flags&IFA_F_TENTATIVE)
>>  			continue;
>> +		write_unlock_bh(&idev->lock);
> 
> This looks weird?!? if 'addr_list' integrity is guaranteed by 
> idev->lock, than this patch looks incorrect. If addr_list integrity is
> ensured elsewhere, why acquiring idev->lock at all?
> 
> @David: can you please comment here?
> 

I have stared at this change a few times. It does look weird and does
not seem to be really solving the problem (or completely solving it).

I think a better option is to investigate moving the locks in the
anycast functions up a layer or two so that the lock here can be held
for the entire list walk.

Re: [PATCH] ipv6: acquire write lock for addr_list in dev_forward_change

[Niels Dossche]

On 17/03/2022 15:45, David Ahern wrote:
> On 3/17/22 5:13 AM, Paolo Abeni wrote:
>> On Wed, 2022-03-16 at 00:02 +0100, Niels Dossche wrote:
>>> No path towards dev_forward_change (common ancestor of paths is in
>>> addrconf_fixup_forwarding) acquires idev->lock for idev->addr_list.
>>> Since addrconf_{join,leave}_anycast acquire a write lock on addr_list in
>>> __ipv6_dev_ac_inc and __ipv6_dev_ac_dec, temporarily unlock when calling
>>> addrconf_{join,leave}_anycast analogous to how it's done in
>>> addrconf_ifdown.
>>>
>>> Signed-off-by: Niels Dossche <dossche.niels@gmail.com>
>>> ---
>>>  net/ipv6/addrconf.c | 4 ++++
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>>> index f908e2fd30b2..4055ded4b7bf 100644
>>> --- a/net/ipv6/addrconf.c
>>> +++ b/net/ipv6/addrconf.c
>>> @@ -818,14 +818,18 @@ static void dev_forward_change(struct inet6_dev *idev)
>>>  		}
>>>  	}
>>>  
>>> +	write_lock_bh(&idev->lock);
>>>  	list_for_each_entry(ifa, &idev->addr_list, if_list) {
>>>  		if (ifa->flags&IFA_F_TENTATIVE)
>>>  			continue;
>>> +		write_unlock_bh(&idev->lock);
>>
>> This looks weird?!? if 'addr_list' integrity is guaranteed by 
>> idev->lock, than this patch looks incorrect. If addr_list integrity is
>> ensured elsewhere, why acquiring idev->lock at all?
>>
>> @David: can you please comment here?
>>
> 
> I have stared at this change a few times. It does look weird and does
> not seem to be really solving the problem (or completely solving it).
> 
> I think a better option is to investigate moving the locks in the
> anycast functions up a layer or two so that the lock here can be held
> for the entire list walk.

Hi
Thanks for the review.
I can write a patch today that fixes it the way you suggest and then send it as a v2.