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

[Jeremy Allison]

On Wed, Apr 16, 2014 at 08:43:52PM +0800, Jones wrote:
> 
> 2014-04-16 3:46 GMT+08:00 Jeremy Allison <jra at samba.org>:
>      OK - Jones, can you test the following
>      patch in your setup ?
> 
> 
> Hello Jeremy,
> 
> Sure! This time looks good!
> 
> After apply this patch:Â 0001-s3-smbd-default_sys_recvfile-and-spice-recvfile-
> were.patch
> per my testing there are 2 different result,
> case A) The transferring progress would still be good to go if EAGAIN is gone.
> case B) The transferring progress would be terminated if EAGAIN keep prompt.
> 
> Please kindly check if followings match the expected result,
> thanks you!
> 
> case B.1) max protocol = NT1
> splice(0x1f, 0, 0x1d, 0xffd9a310, 0x8000, 0) = 32768
> splice(0x1f, 0, 0x1d, 0xffd9a310, 0x8000, 0) = 32768
> splice(0x1f, 0, 0x1d, 0xffd9a310, 0x8000, 0) = 25193
> splice(0x1f, 0, 0x1d, 0xffd9a310, 0x1d97, 0) = 7575
> splice(0x1f, 0, 0x1d, 0xffd9a310, 0x8000, 0) = 24477
> splice(0x1f, 0, 0x1d, 0xffd9a310, 0x2063, 0) = 8291
> splice(0x1f, 0, 0x1d, 0xffd9a310, 0x8000, 0) = 13541
> splice(0x1f, 0, 0x1d, 0xffd9a310, 0x4b1b, 0) = -1 EAGAIN (Resource temporarily
> unavailable)
> splice(0x1f, 0, 0x1d, 0xffd9a310, 0x4b1b, 0) = -1 EAGAIN (Resource temporarily
> unavailable)
> fcntl64(31, F_GETFL) Â  Â  Â  Â  Â  Â  Â  Â  Â  Â = 0x2 (flags O_RDWR)
> fcntl64(31, F_GETFL) Â  Â  Â  Â  Â  Â  Â  Â  Â  Â = 0x2 (flags O_RDWR)
> fcntl64(31, F_SETFL, O_RDWR) Â  Â  Â  Â  Â  Â = 0
> splice(0x1f, 0, 0x1d, 0xffd9a310, 0x4b1b, 0) = -1 EAGAIN (Resource temporarily
> unavailable)
> fcntl64(31, F_SETFL, O_RDWR) Â  Â  Â  Â  Â  Â = 0
> fcntl64(34, F_SETFD, FD_CLOEXEC) Â  Â  Â  Â = 0
> fcntl64(34, F_SETFD, FD_CLOEXEC) Â  Â  Â  Â = 0
> fcntl64(14, F_SETLKW64, {type=F_WRLCK, whence=SEEK_SET, start=684, len=1},
> 0xffd9a264) = 0
> fcntl64(14, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=16244, len=1},
> 0xffd9a264) = 0
> </Terminated later>

> case B.2) max protocol = SMB2_02
> splice(0x1f, 0, 0x8, 0xfff99c70, 0x10000, 0) = 65536
> splice(0x1f, 0, 0x8, 0xfff99c70, 0x10000, 0) = 65536
> splice(0x1f, 0, 0x8, 0xfff99c70, 0x10000, 0) = 59427
> splice(0x1f, 0, 0x8, 0xfff99c70, 0x17dd, 0) = 6109
> splice(0x1f, 0, 0x8, 0xfff99c70, 0x10000, 0) = 30275
> splice(0x1f, 0, 0x8, 0xfff99c70, 0x89bd, 0) = 14600
> splice(0x1f, 0, 0x8, 0xfff99c70, 0x50b5, 0) = -1 EAGAIN (Resource temporarily
> unavailable)
> splice(0x1f, 0, 0x8, 0xfff99c70, 0x50b5, 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, 0x8, 0xfff99c70, 0x50b5, 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=632, len=1},
> 0xfff99d44) = 0
> fcntl64(13, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=31936, len=1},
> 0xfff99d44) = 0
> </Terminated later>
> 
> 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.

Jeremy.