On 04/08/2013 05:06 PM, Al Viro wrote: > On Mon, Apr 08, 2013 at 03:45:31PM -0700, Doug Anderson wrote: >> Hi, >> >> On Mon, Apr 8, 2013 at 3:17 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: >>>> Anyway, I've just pushed a splitup of that commit (carved in 3 pieces) >>>> into vfs.git#pipe-splitup; could you check which part triggers that >>>> hang? Should propagate in a few... >>> >>> It looks like "pipe: unify ->release() and ->open()" introduces the >>> problem. Note that I had to add a prototype for fifo_open() before the >>> structs that reference it for that commit to compile. >> >> It sounds like Stephen has provided you the info you needed so not >> doing any extra testing now, but I figured I'd chime in that I hit >> problems this morning with linux-next and it appears to be the same >> thing. I did a revert of 9984d7394618df9 and (plus a revert of a >> handful of patches to the same file) and problems are resolved. The >> failure case is really weird in that everything works well booting to >> a simple /bin/bash but fails when you do more complex tasks. >> >> Anyway: If you need some extra testing feel free to CC me. > > Folks, see if vfs.git#experimental works for you; the PITA had apparently > been caused by change of open() semantics for /proc/<pid>/fd/<some_pipe> - > it started to behave like a FIFO, i.e. wait for peer to show up. Normally > that's not a problem, but if you have closed e.g. the write end of a pipe > and try to open /proc/<pid>/fd/<read_end_of_pipe>, you'll get open() waiting > for writers to appear. Which isn't what we used to do here (open succeeded > immediately) and apparently that was enough to trip drakut. > > Branch head should be at 574179469f7370aadb9cbac1ceca7c3723c17bee. That branch works. Thanks! -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html