Messages in this thread | | | Date | Thu, 25 Feb 1999 17:15:28 -0800 | From | David Miller <> | Subject | Re: TCP quickack race ? (Was Problem: sending mail ...) |
| |
From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Fri, 26 Feb 1999 02:05:42 +0000 (GMT)
> 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/
| |