If soreceive() is called from a socket callback, there's no reason

to do a window update to the peer (thru an ACK) from soreceive()
itself. TCP will do that upon return from the socket callback.
Sending a window update from soreceive() results in a lock reversal.

Submitted by:	Mohan Srinivasan mohans at yahoo-inc dot com
Reviewed by:	rwatson
This commit is contained in:
Paul Saab 2004-11-29 23:10:59 +00:00
parent 85d11adf25
commit d297f70246
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=138206
2 changed files with 10 additions and 1 deletions

View File

@ -1388,7 +1388,13 @@ soreceive(so, psa, uio, mp0, controlp, flagsp)
}
SBLASTRECORDCHK(&so->so_rcv);
SBLASTMBUFCHK(&so->so_rcv);
if (pr->pr_flags & PR_WANTRCVD && so->so_pcb) {
/*
* If soreceive() is being done from the socket callback, then
* don't need to generate ACK to peer to update window, since
* ACK will be generated on return to TCP.
*/
if (!(flags & MSG_SOCALLBCK) &&
(pr->pr_flags & PR_WANTRCVD) && so->so_pcb) {
SOCKBUF_UNLOCK(&so->so_rcv);
(*pr->pr_usrreqs->pru_rcvd)(so, flags);
SOCKBUF_LOCK(&so->so_rcv);

View File

@ -396,6 +396,9 @@ struct msghdr {
#define MSG_NBIO 0x4000 /* FIONBIO mode, used by fifofs */
#define MSG_COMPAT 0x8000 /* used in sendit() */
#endif
#ifdef _KERNEL
#define MSG_SOCALLBCK 0x10000 /* for use by socket callbacks - soreceive (TCP) */
#endif
/*
* Header for ancillary data objects in msg_control buffer.