On Fri, Mar 25, 2016 at 11:11 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Fri, 2016-03-25 at 10:17 -0700, Cong Wang wrote: > >> 1) sock lock protects the whole update: the whole check, update, recheck, >> set logic, to make sure another CPU will not do the same to the same socket >> at the same time. >> >> 2) the dst itself is safe, because it is always refcounted, and we use xchg() >> to change the pointer in sk_dst_cache. >> >> Or am I still missing anything here? > > As TCP always lock the socket before doing its heavy stuff, > it can use a variant of sk_dst_cache manipulations that do not use extra > atomic operations. > > But UDP gets xchg() to safely exchange sk_dst_cache, because we do not > feel locking the socket is needed for UDP for typical uses (! cork) > > If you hold the socket lock in ICMP handler, then it would be > inconsistent with udp sendmsg() where we do not hold the socket lock. > > Since I believe udp sendmsg() is fine, I do believe you do not need to > lock the socket, and then care about socket being owned by the user.
I see, seems the whole update logic is safe to become lock-free, then commit 8141ed9fcedb278f4a3a78680591bef1e55f75fb can be just reverted. OTOH, other bh_lock_sock() callers need it to update queues etc., here we only need to check and update one single pointer in sk. Steffen? Thanks.
