On Wed, Oct 16, 2019 at 4:24 PM David Howells <dhowe...@redhat.com> wrote: > > Eric Dumazet <eduma...@google.com> 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 lock? > > Looking at __udp4_lib_err(), that calls __udp4_lib_err_encap(), which calls > __udp4_lib_err_encap_no_sk(), which should throw a warning if the RCU read > lock is not held. > > Similarly, icmp_socket_deliver() and icmpv6_notify() should also throw a > warning before calling ->err_handler(). > > Does that mean something further up the CPU stack is going to be holding the > RCU read lock?
Note that before my patch, the code had a rcu_read_lock()/rcu_read_unlock(), so I only extended it. I am not sure that all callers already have rcu_read_lock() held, I prefer leaving this matter for net-next > > David
