On Sat, 2017-08-26 at 07:53 +0200, Ivan Delalande wrote: > > Sorry, I probably should have detailed my changes. I tried to address > this by locking the whole socket in the caller, tcp_diag_get_aux, just > outside of the rcu_read_lock. Would this work here, or do you see a > better way? >
locking the socket is problematic. It is already done in tcp_get_info() since linux-4.10 and unfortunately it added unreasonable stall when a socket is flooded with tiny SACK messages (socket backlog is huge) People are now making tcp_rmem and tcp_wmem much bigger to allow BBR flows to reach line rate on very long distance communications. We are working to make tcp_rack_mark_lost() not having O(N) behavior, but it is not done yet. I would stick to RCU, but add sanity checks, so that _if_ the list is different on the second RCU list traversal, you make sure : 1) We do not try to put more data in the reserved space 2) We memset(ptr, 0, remaining) the remaining space if we found less entries in the 2nd loop.
