[distcc] sendfile.c out of date comment. Bug in linux-2.6.12's 32 bit sendfile on x86_64.

[Daniel Kegel]

Looks like the comment in src/sendfile.c
  * Our sockets are never non-blocking, so that seems to me to say that
  * the kernel will never return EAGAIN -- we will always either send
  * the whole thing or get an error.  Is that really true?
needs updating, since the socket was set to nonblocking in dcc_connect_by_addr().
- Dan

p.s. We noticed this while tracking down the following problem:

On an x86_64 system running a 64 bit 2.6.12 kernel and a 32
bit version of distcc, things weren't working at all.

We used strace and tcpdump to observe distcc sending a 35198 byte file:

3037  sendfile(5, 3, [0], 35198)        = 11041
3037  sendfile(5, 3, [0], 24157)        = -1 EAGAIN (Resource temporarily unavailable)
3037  sendfile(5, 3, [0], 24157)        = 10136
3037  sendfile(5, 3, [0], 14021)        = -1 EAGAIN (Resource temporarily unavailable)
3037  sendfile(5, 3, [0], 14021)        = 14021

tcpdump shows that after sending the first 11041
bytes, it sends them again.  So the second sendfile hasn't advanced
the file pointer at all... which is exactly what you see in the output
of strace.

strace on a 32 bit system shows the offset incrementing nicely:

2396  sendfile(5, 3, [0], 37077)        = 12782
2396  sendfile(5, 3, [12782], 24295)    = -1 EAGAIN (Resource temporarily unavailable)
2396  sendfile(5, 3, [12782], 24295)    = 14480
2396  sendfile(5, 3, [27262], 9815)     = -1 EAGAIN (Resource temporarily unavailable)
2396  sendfile(5, 3, [27262], 9815)     = 9815

Looks like it's a bug in 2.6.12; 2.6.14 has a little change in arch/x86_64/ia32/sys_ia32.c:

-       if (!ret && offset && put_user(of, offset))
+       if (offset && put_user(of, offset))

- Dan