Socket draining for sys_recvfile() (patch for 'reverse sendfile')
jra at samba.org
Fri Dec 30 20:27:48 MST 2011
On Sat, Dec 31, 2011 at 02:04:18PM +1100, Andrew Bartlett wrote:
> On Fri, 2011-12-30 at 18:53 -0800, Jeremy Allison wrote:
> > On Fri, Dec 30, 2011 at 05:57:42PM -0800, Jeremy Allison wrote:
> > > I took a quick look at your capture and it seems to be returning successes
> > > to all the writes in the first test case. Not sure where the client is
> > > detecting NT_STATUS_INVALID_NETWORK_RESPONSE in the replies.
> > >
> > > Can you split out the success and fail captures into 2 different files ?
> > >
> > > (I'll try and take a look at this, family time permitting - over the
> > > next few days).
> > Just FYI for anyone following - I set up the
> > same (small usb drive nearly full, min recvfile size = 1
> > set in smb.conf) and the problem doesn't happen in
> > the normal (non-splice) codepath - smbclient gets
> > STATUS_DISK_FULL on write.
> > Phew. I didn't think we were *that* broken :-). I'll
> > look into enabling the non-default splice codepath
> > next and see if I can reproduce with that.
> Which smbclient did you use? You need to use smbclient3 from master,
> not smbclient (which will shortly be renamed smbclient4) because the
> Samba4 client libs have a different padding which means we never hit the
> recvfile hook.
> Also, I misstated the smb.conf option, it is 'min receivefile size = 1'.
> My latest testing was on my x86 laptop, with unpatched master, on a
> unpatched Fedora 15 kernel.
> Hopefully this will help you reproduce,
Still working on it, but I've now reproduced (problem was signing
was on, which meant no recvfile allowed). I understand the problem
now - working on the minimal patch.
Underlying issue is confusing return value from default_sys_recvfile().
On short write it should return the short bytes written, on bad read
it needs to return -1.
It's not doing that :-(.
More information about the samba-technical