Socket draining for sys_recvfile() (patch for 'reverse sendfile')

[Andrew Bartlett]

Volker and Jermey,

I've been working on the attached patch to implement sys_recvfile() for
a kernel that has been patched to allow sendfile from a socket to a
file.  (Patch for 3.5.11). 

I notice in the git history that this seems to be your area, and that
you have had trouble with recvfile in practice, with concerns about
blocking and the current code being effectively disabled in master.  

As such, I'm hoping you might be able to help me out in understanding
this area.  

In particular, what is the purpose of the 'socket draining' code?  I'm a
little confused, because the comments at the callers
(source3/smbd/vfs.c) indicate it is expected, but it is only explicitly
in the splice() code path in source3/lib/recvfile.c and not in the
read/write 'fallback' (which is actually what we always use). 

Finally, is there anything else should I know or be looking out for?

Thanks, 

Andrew Bartlett

(As a hint to others, I've found that Samba4 client libs underpinning
smbtorture do not trigger the recvfile path, but smbclient3 does.  This
is apparently a well known behaviour difference of one padding/alignment
byte in the WriteX packet)

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: recvfile.patch
Type: text/x-patch
Size: 1801 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20111222/e6a9d8de/attachment.bin>