On Wed, Oct 16, 2019 at 4:24 PM David Howells wrote:
>
> Eric Dumazet wrote:
>
> > We need to extend the rcu_read_lock() section in rxrpc_error_report()
> > and use rcu_dereference_sk_user_data() instead of plain access
> > to sk->sk_user_data to make sure all rules are respected.
>
> Should I ta
Eric Dumazet wrote:
> We need to extend the rcu_read_lock() section in rxrpc_error_report()
> and use rcu_dereference_sk_user_data() instead of plain access
> to sk->sk_user_data to make sure all rules are respected.
Should I take it that the caller won't be guaranteed to be holding the RCU
read
From: Eric Dumazet
Date: Mon, 14 Oct 2019 06:04:38 -0700
> We need to extend the rcu_read_lock() section in rxrpc_error_report()
> and use rcu_dereference_sk_user_data() instead of plain access
> to sk->sk_user_data to make sure all rules are respected.
>
> The compiler wont reload sk->sk_user_d
From: Eric Dumazet
Date: Mon, 14 Oct 2019 06:04:38 -0700
> We need to extend the rcu_read_lock() section in rxrpc_error_report()
> and use rcu_dereference_sk_user_data() instead of plain access
> to sk->sk_user_data to make sure all rules are respected.
>
> The compiler wont reload sk->sk_user_d
We need to extend the rcu_read_lock() section in rxrpc_error_report()
and use rcu_dereference_sk_user_data() instead of plain access
to sk->sk_user_data to make sure all rules are respected.
The compiler wont reload sk->sk_user_data at will, and RCU rules
prevent memory beeing freed too soon.
Fix
