Re: splice/tee bugs?

[Michael Kerrisk]

> > Could you post a 2.6.17 patch please.
> 
> Here's a 2.6.17.x version.

Jens,

Thanks.  I applied your patch against 2.6.17(.0), and did some
testing using my modified version of your test program, using 
the same command line: ls *.c | ktee r | wc, and also running 
several instances of the program in parallel using the 
command line:

find . | ktee r | wc

which in my test directory produces this output:

tee returned 65536
splice returned 65536
tee returned 65536
splice returned 65536
tee returned 53248
splice returned 53248
tee returned 57344
splice returned 57344
tee returned 7245
splice returned 7245
tee returned 0
   6212    6213  248909

Things look good so far: runs produce the results I expect, and 
no OOPSes (which Luiz Fernando reported when running multiple
instances in parallel, but I didn't see myself because I didn't
try doing that with vanilla 2.6.17) and no command-line hangs.

I'll quote my original mail in this thread, with a few questions,
and then note one lingering strange behaviour.

> The most notable differences between my program and yours
> are:
>
> * I print some debugging info to stderr.
>
> * I don't pass SPLICE_F_NONBLOCK to tee().
[...]
> On different runs I see:
>
> a) No output from ls through the pipeline:
>
> tee returned 0
>       0       0       0

I am no longer seeing results like this. So am I correct in 
understanding that tee() should only return 0 on EOF?

And is the same true of splice()?  (There is no statement 
about 0 returns from splice() in your draft manual page.)

> b) Very many instances of EAGAIN followed by expected results:
>
> ...
> EAGAIN
> EAGAIN
> EAGAIN
> EAGAIN
> EAGAIN
> EAGAIN
> tee returned 19
> splice returned 19
> tee returned 0
>       2       2      19
[...]

I no longer see results like this.  From another of your mails
in this thread, I gather that intended behaviour is that EAGAIN
will only occur if SPLICE_F_NONBLOCK has been set, right?

> c) Occasionally the command line just hangs, producing no output.
>    In this case I can't kill it with ^C or ^\.  This is a
>    hard-to-reproduce behaviour on my (x86) system, but I have
>    seen it several times by now.

I no longer see this behaviour (at least so far, after quite a
bit of testing).

One slight strangeness.  Most of the time, the 
"find . | ktee r | wc" command line takes about 0.1 seconds to 
execute, but about 1 time in 5 on my x86 system, it takes about 
1.5 to 2 seconds to execute.  Any ideas about what's happening 
there?

Cheers,

Michael
-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  
Grab the latest tarball at
ftp://ftp.win.tue.nl/pub/linux-local/manpages/, 
read the HOWTOHELP file and grep the source 
files for 'FIXME'.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/