On Wed, Apr 24, 2019 at 11:29:25AM -0700, Eric Dumazet wrote:
> On Wed, Apr 24, 2019 at 11:21 AM Guillaume Nault wrote:
>
> >
> > And then, we'd need to make sure that ->sk_user_data is in sync with
> > the encap_rcv() callback (or whatever actually uses the data pointed
> > to). Otherwise a modu
On Wed, Apr 24, 2019 at 11:21 AM Guillaume Nault wrote:
> It seems that callers of rcu_assign_sk_user_data() can indeed sleep.
>
> But I think we have more problems. Not all code paths treat
> ->sk_user_data as RCU pointers (IIUC that's why we created the
> __sk_user_data() macro, instead of just
On Wed, Apr 24, 2019 at 04:33:47AM -0700, Eric Dumazet wrote:
> On Wed, Apr 24, 2019 at 2:58 AM Guillaume Nault wrote:
> >
> > On Tue, Apr 23, 2019 at 09:43:26AM -0700, Eric Dumazet wrote:
> > > Canonical way to fetch sk_user_data from an encap_rcv() handler called
> > > from UDP stack in rcu prot
On Wed, Apr 24, 2019 at 2:58 AM Guillaume Nault wrote:
>
> On Tue, Apr 23, 2019 at 09:43:26AM -0700, Eric Dumazet wrote:
> > Canonical way to fetch sk_user_data from an encap_rcv() handler called
> > from UDP stack in rcu protected section is to use
> > rcu_dereference_sk_user_data(),
> > otherwi
On Tue, Apr 23, 2019 at 09:43:26AM -0700, Eric Dumazet wrote:
> Canonical way to fetch sk_user_data from an encap_rcv() handler called
> from UDP stack in rcu protected section is to use
> rcu_dereference_sk_user_data(),
> otherwise compiler might read it multiple times.
>
That reminds me the mor
Canonical way to fetch sk_user_data from an encap_rcv() handler called
from UDP stack in rcu protected section is to use
rcu_dereference_sk_user_data(),
otherwise compiler might read it multiple times.
Fixes: d00fa9adc528 ("il2tp: fix races with tunnel socket close")
Signed-off-by: Eric Dumazet
