Must really be safe_read(),not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)

[Paul Albrecht]

On Thu, 2007-02-15 at 17:02 -0500, Rob Landley wrote:
> On Tuesday 13 February 2007 8:58 am, Paul Albrecht wrote:
> > However, I still think that because the read syscall is unbuffered you
> > can't assume that if you write x bytes to one end of the pipe you're
> > guaranteed x bytes on the *first* read on the other end of the pipe.
> 
> http://www.opengroup.org/onlinepubs/009695399/functions/write.html
> 
>   After a write() to a regular file has successfully returned:
>     o Any successful read() from each byte position in the file that was
>       modified by that write shall return the data specified by the write()
>       for that position until such byte positions are again modified.
> 
>   Write requests to a pipe or FIFO shall be handled in the same way as a
>   regular file with the following exceptions:
>     o There is no file offset associated with a pipe, hence each write request
>       shall append to the end of the pipe.
>     o Write requests of {PIPE_BUF} bytes or less shall not be interleaved with
>       data from other processes doing writes on the same pipe.
> 
> Yes, you can.
> 

Thanks for clarifying what the standard is for pipes, but this doesn't
really help much because it's a fact that busybox httpd fails
intermittently when the I run a simple cgi script to redirect a request.

It doesn't seem to me to do much good to fall back on a standard if the
it isn't applicable in the real world. The user receiving garbage back
from a web server doesn't really care if the server is standard
conforming or not.

> > I think you're supposed to check the number of bytes read and continue
> > doing reads until you get as much data as you're expecting or get end of
> > file.
> 
> A pipe is attached to a kernel buffer which his updated atomically by write() 
> and read() syscalls.  There is _cannot_ be any propogation delay, nor partial 
> writes of less than PIPE_BUF, in an SUSv3 compliant pipe implementation.  The 
> spec says so.

Again, it's a fact that a simple cgi program that returns status back to
the busybox httpd server will intermittently fail in the manner I have
previously described.

If you're suggesting the it's a kernel bug perhaps you should post it to
the linux kernel mailing list because that's what I'm using for an
operating system.