Dealing with the sendfile mess

[James Peach]

On Thu, Oct 21, 2004 at 08:51:31AM +1000, Andrew Bartlett wrote:
> 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.

Yep, I came across this adding while sendfile support to IRIX. My
(pretty obvious) solution was to detect the presence of a working
sendfile before trying to use it in anger. If it's not there, always
return ENOSYS without sending headers.

> 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.

So this would be the zero-filling behaviour Jeremy talked about at one
point?
 
> 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.

This sounds like a useful refactorisation of the read reply paths. 

-- 
James Peach | jpeach at sgi.com | SGI Australian Software Group
I don't speak for SGI.