Dealing with the sendfile mess

Andrew Bartlett abartlet at
Thu Oct 21 00:34:10 GMT 2004

On Thu, 2004-10-21 at 10:15, Jeremy Allison wrote:
> On Thu, Oct 21, 2004 at 08:51:31AM +1000, Andrew Bartlett wrote:
> > 
> > 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.
> Is it a case of sendfile just failing ? I never got a good
> report of the exact problem.

That's why I decided to start discussion here, as I think it's possible
to prove this issue from source code.

Presume that for some reason sendfile fails - Steve claimed it was
possible for it to return ENOSYS in odd situations.  Currently, we
exit_server() for any other error, and send headers twice for ENOSYS
(see the goto in the write&X code). 

> > 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.
> Actually we don't have to handle this case, tridge proved that
> returning zeros is ok here.

My point exactly.  We just need to actually do this (looking at the
code, I think we exit_server() instead).

> The returning the header twice is just a bug and we should
> be able to fix that. The issue is how do we know the header
> has been returned ? If the sendfile failed - where in the
> returning stream did it fail ? 

See, the problem is that linux sendfile does not take a headers
argument, and sys_sendfile() in this case does the write, then asks
sendfile to send the data.

I'm proposing that the 'sendfile failed' code should be specific to the
sys_sendfile() implementation.  This will allow us to tell where it
failed, and chose the appropriate recovery.  (Which may still be

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