Re: fd-passing (mis)behaviour: confirm/refute?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Could I possibly get you to ktrace it or some such to find out
>> what's making it die?

> One process gets a SIGPIPE.

>  25570      1 unfdstress CALL  write(0xb,0x11e14,0xa)
>  25570      1 unfdstress RET   write -1 errno 32 Broken pipe
>  25570      1 unfdstress PSIG  SIGPIPE SIG_DFL: code=SI_NOINFO

Okay, that's a failure mode I hadn't seen myself and didn't trap.  I'm
not sure whether I'd rather ignore SIGPIPE and let EPIPE happen or set
up a SIGPIPE handler, but I probably should do one of the two.

Those systems, then, are manifesting the problem, in that the stressing
processes are causing unrelated processes to see connections as broken
when they shouldn't be.

> Before that, everything is fighting to synchronize and most sendmsg()
> and write() fail with ENOBUFS.

Yup, that's the stressing processes operating as designed.  They send
vigorously - see busy_a() and busy_b().

Interestingly, I have since tested it on (mutant) 4.0.1 and it works
just fine, even under stress.  I can't as test it on 1.4T because the
program is written to the broken CMSG_* API, which 1.4T predates.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B