Messages in this thread | | | From | (Alan Cox) | Subject | TCP quickack race ? (Was Problem: sending mail ...) | Date | Fri, 26 Feb 1999 00:47:44 +0000 (GMT) |
| |
> + if(th->psh && (skb->len < (tp->mss_cache >> 1))) { > + /* Preserve the quickack state. */ > + if((tp->ato & 0x7fffffff) > HZ/50) > + tp->ato = ((tp->ato & 0x80000000) | > + (HZ/50));
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
Alan
- 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/
| |