Re: Possible problem with zero-copy TCP and sendfile()

[David S. Miller]

Jesse S Sipprell writes:
 > A patch will be coming out soon, as it is a fairly trivial fix.

Thank you for tracking this down.

One more subtle note, for the case of error handling.  There is a
change to sendfile() in the zerocopy patches which causes sendfile()
to act more like sendmsg() when errors occur.

Specifically, sendmsg() works roughly like the following when an
error happens:

handle_error:
	if (sent_something)
		return how_much_we_sent;
	else
		return ERROR_CODE;

So when an error happens, and the kernel was able to send some of
the data, you see something like this in the trace:

	sendmsg() = N
	...
	sendmsg() = ERROR_CODE

sendfile() used to act differently, and this made it difficult to
directly transform a sendmsg()+local_buffer based server into a
sendfile() one because the error handling was so different.

Previously, sendfile() wouldn't give you the partial transfer length,
you'd just get the error _regardless_ of whether any data was sent
successfully during that call.  Alexey, myself, and others considered
this behavior bogus and inconsistent.  So it was changed.

The long and short of it is that sendfile() now acts just like
sendmsg() when errors happen mid-send.

Later,
David S. Miller
[e-mail]