> doing anything with these bits of state. In fact I do not know of any
> TCP code paths from user context (besides backlog processing, which
> again is BH protected) which mess with tp->ato
Hohum
tcp_recvmsg->cleanup_rbuf -> tcp_read_wakeuk -> tcp_send_ack
Now that does appear to be a locked path.
Right, my main point is that if any code path could cause a problem
with messing with tp->ato, it would be fundamentally broken because it
would be:
1) Messing with tcp_opt state
2) Doing so outside of BH _or_
3) Doing so outside of lock_sock
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/