Re: [PATCH v2] tcp: fix MSG_PEEK race check

[David Miller <davem@davemloft.net>]

From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Tue, 19 May 2009 07:33:02 +0300 (EEST)

> Sure, the copied_seq is moving, but what I'm after is that does it really 
> make any difference from tcp_recvmsg point of view? It certainly triggers 
> the message but that won't work as a proof of the evilness for me.
> 
> ...The above paragraph is assuming recvmsg is able to deal with that and 
> doesn't choke because of the changing copied_seq. I'd have to audit it 
> once again to verify that it's really ok but I don't see any particular 
> reason why it couldn't be possible to make recvmsg to not care on the 
> tcp_check_urg side copied_seq changes but I'd like to hear a clear 
> confirmation on that from you too.

recvmsg can deal with it fine, because we reset the peek_seq when we
print out that message.

There is no way that an application writer has any clue about this
interaction, where peeked bytes disappear and then reappear in
the out-of-band URG byte.  That's why the message is there.