* [RFC] ifa_list needs proper rcu protection
@ 2019-04-25 22:50 Eric Dumazet
2019-05-04 18:01 ` Florian Westphal
0 siblings, 1 reply; 3+ messages in thread
From: Eric Dumazet @ 2019-04-25 22:50 UTC (permalink / raw)
To: Networking; +Cc: David Ahern, Florian Westphal
It looks that unless RTNL is held, accessing ifa_list needs proper RCU protection ?
indev->ifa_list can be changed under us by another cpu (which owns RTNL)
Lets took an example.
(A proper rcu_dereference() with an happy sparse support would require adding __rcu attribute,
I put a READ_ONCE() which should be just fine in this particular context)
diff --git a/net/netfilter/nf_nat_redirect.c b/net/netfilter/nf_nat_redirect.c
index 78a9e6454ff3d712926397beb904b478b8fab0f1..8619b8d02b0530c5735c31d029f1d79969d979c7 100644
--- a/net/netfilter/nf_nat_redirect.c
+++ b/net/netfilter/nf_nat_redirect.c
@@ -48,14 +48,17 @@ nf_nat_redirect_ipv4(struct sk_buff *skb,
newdst = htonl(0x7F000001);
} else {
struct in_device *indev;
- struct in_ifaddr *ifa;
newdst = 0;
indev = __in_dev_get_rcu(skb->dev);
- if (indev && indev->ifa_list) {
- ifa = indev->ifa_list;
- newdst = ifa->ifa_local;
+ if (indev) {
+ struct in_ifaddr *ifa;
+
+ ifa = READ_ONCE(indev->ifa_list); // rcu_dereference(xxx)
+
+ if (ifa)
+ newdst = ifa->ifa_local;
}
if (!newdst)
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [RFC] ifa_list needs proper rcu protection
2019-04-25 22:50 [RFC] ifa_list needs proper rcu protection Eric Dumazet
@ 2019-05-04 18:01 ` Florian Westphal
2019-05-04 18:06 ` Eric Dumazet
0 siblings, 1 reply; 3+ messages in thread
From: Florian Westphal @ 2019-05-04 18:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Networking, David Ahern, Florian Westphal
Eric Dumazet <eric.dumazet@gmail.com> wrote:
Sorry for late reply.
> It looks that unless RTNL is held, accessing ifa_list needs proper RCU protection ?
>
> indev->ifa_list can be changed under us by another cpu (which owns RTNL)
>
> Lets took an example.
>
> (A proper rcu_dereference() with an happy sparse support would require adding __rcu attribute,
> I put a READ_ONCE() which should be just fine in this particular context)
I don't see e.g. __inet_insert_ifa() use rcu_assign_pointer() or similar
primitive, so I don't think its enough to change readers.
Same for __inet_del_ifa(), i see freeing gets dealyed via call_rcu, but
it uses normal assignemts instead of a rcu helper.
So, I am afraid we will have to sprinkle some rcu_assign_/derefence in
several places.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] ifa_list needs proper rcu protection
2019-05-04 18:01 ` Florian Westphal
@ 2019-05-04 18:06 ` Eric Dumazet
0 siblings, 0 replies; 3+ messages in thread
From: Eric Dumazet @ 2019-05-04 18:06 UTC (permalink / raw)
To: Florian Westphal; +Cc: Networking, David Ahern
On 5/4/19 2:01 PM, Florian Westphal wrote:
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> Sorry for late reply.
>
>> It looks that unless RTNL is held, accessing ifa_list needs proper RCU protection ?
>>
>> indev->ifa_list can be changed under us by another cpu (which owns RTNL)
>>
>> Lets took an example.
>>
>> (A proper rcu_dereference() with an happy sparse support would require adding __rcu attribute,
>> I put a READ_ONCE() which should be just fine in this particular context)
>
> I don't see e.g. __inet_insert_ifa() use rcu_assign_pointer() or similar
> primitive, so I don't think its enough to change readers.
>
> Same for __inet_del_ifa(), i see freeing gets dealyed via call_rcu, but
> it uses normal assignemts instead of a rcu helper.
>
> So, I am afraid we will have to sprinkle some rcu_assign_/derefence in
> several places.
Yes, I came to the same conclusion.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-05-04 18:06 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-04-25 22:50 [RFC] ifa_list needs proper rcu protection Eric Dumazet
2019-05-04 18:01 ` Florian Westphal
2019-05-04 18:06 ` Eric Dumazet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox