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/