[PATCH] Fix RECVFILE with non-blocking sockets and add OEM recvfile call.

[Jeremy Allison]

On Thu, May 22, 2014 at 06:18:30PM +0200, Stefan (metze) Metzmacher wrote:
> Am 22.05.2014 17:59, schrieb Jeremy Allison:
> > On Thu, May 22, 2014 at 02:59:09PM +0200, Stefan (metze) Metzmacher wrote:
> >>
> >> I'm getting EINVAL from splice if I use large io sizes, when using SMB3.
> >> When count is truncated to TRANSFER_BUF_SIZE (128*1024) it works fine.
> > 
> > OK, I'll fix up the 'standard' splice code on top of these patches
> > to make sure we don't go over 128k. Justin's splice changes won't
> > have that problem as he's using custom kernel code here.
> 
> I was testing with a custom kernel! And the patches an OEM gave me look
> similar,
> but the have the chunking. With chunking it worked fine without I got a
> disconnect
> from the server.
> 
> For the 'standard' splice we could use larger chunks, as current kernel
> allow
> F_SETPIPE_SZ up to 1MB.

FYI. I just did some tests with changing
the F_SETPIPE_SZ to 1MB, and then changing
the count size to match, and that causes
the server to stop responding to client
requests by being stuck inside a non-responsive
splice() call...

The current kernel splice does seem to
be a complete crock of shit I'm afraid :-(.

I'm still investigating, but I'm starting to
think that I need to abandon the Netgear Samba
patch for now as the kernel fix can cause
the splice() to return EAGAIN even when the
socket has been set back to blocking (as
it messes with the sk_timeout values in
a completely arbitrary way without
userspace being aware of it - see the
problems Jones has been having for details.

Maybe we should revisit the LINUX_SPLICE_SOCKET_TO_FILE
patch once the kernel code is known to actually,
you know, work ! :-).

Cheers,

	Jeremy.