[PATCH] Fix bug 9412 - SMB2 server doesn't support recvfile.

[Jeremy Allison]

On Wed, Apr 16, 2014 at 11:55:40AM -0700, Jeremy Allison wrote:
> > 
> > case B.3) max protocol = SMB2_10
> > splice(0x1f, 0, 0x1d, 0xffa81cc0, 0x20000, 0) = 131072
> > splice(0x1f, 0, 0x1d, 0xffa81cc0, 0x20000, 0) = 131072
> > splice(0x1f, 0, 0x1d, 0xffa81cc0, 0x20000, 0) = 81130
> > splice(0x1f, 0, 0x1d, 0xffa81cc0, 0x20000, 0) = 37960
> > splice(0x1f, 0, 0x1d, 0xffa81cc0, 0x20000, 0) = 26280
> > splice(0x1f, 0, 0x1d, 0xffa81cc0, 0x20000, 0) = -1 EAGAIN (Resource temporarily
> > unavailable)
> > splice(0x1f, 0, 0x1d, 0xffa81cc0, 0x20000, 0) = 7300
> > splice(0x1f, 0, 0x1d, 0xffa81cc0, 0x20000, 0) = -1 EAGAIN (Resource temporarily
> > unavailable)
> > splice(0x1f, 0, 0x1d, 0xffa81cc0, 0x20000, 0) = -1 EAGAIN (Resource temporarily
> > unavailable)
> > fcntl64(31, F_GETFL) Â  Â  Â  Â  Â  Â  Â  Â  Â  Â = 0x802 (flags
> > O_RDWR|O_NONBLOCK)
> > fcntl64(31, F_GETFL) Â  Â  Â  Â  Â  Â  Â  Â  Â  Â = 0x802 (flags
> > O_RDWR|O_NONBLOCK)
> > fcntl64(31, F_SETFL, O_RDWR) Â  Â  Â  Â  Â  Â = 0
> > splice(0x1f, 0, 0x1d, 0xffa81cc0, 0x20000, 0) = -1 EAGAIN (Resource temporarily
> > unavailable)
> > fcntl64(31, F_SETFL, O_RDWR|O_NONBLOCK) = 0
> > fcntl64(13, F_SETLKW64, {type=F_WRLCK, whence=SEEK_SET, start=492, len=1},
> > 0xffa81d94) = 0
> > fcntl64(13, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=31936, len=1},
> > 0xffa81d94) = 0
> 
> Hmmmmm. In all these cases above, why is splice()
> returning EAGAIN *after* the socket has been set
> to blocking mode (which is clearly happening).
> 
> Volker suggested this might be coming from
> the pipe.... but I don't see why or how this
> can happen.
> 
> Looks like a splice bug to me. Are you using
> a custom splice call or just the normal kernel
> splice ?
> 
> I'll look into the kernel splice to see if
> this is possible.

OK, I looked really closely at the kernel
source code (3.2.x - just what I had handy :-).

Once the input socket is set to blocking
mode, then the only way splice() can
return EAGAIN is if the flag SPLICE_F_NONBLOCK
is passed into splice - which we don't
do.

So I can't currently see any way that
splice can return EAGAIN once the
input socket is set to blocking mode.

Are you using a custom splice() call ?

If not, what kernel are you using so
I can look at exactly the source code
you have ?

Jeremy.