Messages in this thread | | | Date | Thu, 25 Feb 1999 17:03:19 -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 00:47:44 +0000 (GMT)
Well the &0x8000000 stuff is suspicious.
Firstly the operation isnt atomic. So a user program on another CPU could clash with the above and end up entering/leaving quickack mode in error. That would only be safe if tp->ato is only touched from net_bh/timer_bh. That doesnt appear to be the case.
Secondly tcp_send_delayed_ack reads the timeout but doesnt mask the quickack bit. I think this latter one is in itself Ok because the quickack is exited before its called
It all runs from BH context only, the rest of the quickack code does the same exact "non-atomic" thing. The code paths in question always run in BH with knowledge that they have the socket to themselves. All user contexts will do lock_sock() (and thus synchronize_bh() ) before 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
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/
| |