Dealing with the sendfile mess

Andrew Bartlett abartlet at
Wed Oct 20 22:51:31 GMT 2004

Samba 3.0.7 has been rather a mess, due to the change in the default of
'use sendfile'.  The failure cases for this call are not well handled,
causing mayhem particularly with Linux clients.  

Steve French caught me on IRC and described it, but hasn't mentioned it
here, so I figured I needed to raise it.  It is important, because of
the potential for data corruption.

The issue, as Steve discovered, is that on failure, our sendfile code
will revert to a *normal* read request, despite having already sent the
SMB header.  This means the header is sent twice, and it all goes to
mush from here.

As we discussed on IRC, there seem to be two fixes we need.  We just
need to handle normal error cases better - file truncated under us etc,
and the lack of a functioning sendfile() at any given moment.

We can do this by having sys_sendfile() handle all the cases, and
avoiding the two codepaths that caused this bug to occur in the first
place.  If sys_sendfile() were implemented for systems without a real
sendfile() API, then we would always take the same codepath.  Likewise,
if the sendfile() call fails, we should just continue with read() and
write(), but within the sys_sendfile() call.

If this is all just a bit too much, then we need to get 'use sendfile'
turned back off, until we have time to deal with this properly.

Andrew Bartlett
Andrew Bartlett                                 abartlet at
Authentication Developer, Samba Team  
Student Network Administrator, Hawker College   abartlet at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :

More information about the samba-technical mailing list