On Fri, 2013-02-22 at 13:37 -0500, Peter Hurley wrote: > On Thu, 2013-02-21 at 08:38 -0500, Peter Hurley wrote: > > On Thu, 2013-02-21 at 08:16 -0500, Sasha Levin wrote: > > > On 02/20/2013 03:02 PM, Peter Hurley wrote: > > > > Sasha and Dave, my trinity testbeds die in other areas right now; > > > > I would really appreciate if you would please re-test this series. > > > > > > Hi Peter, > > > > > > I saw this twice in overnight fuzzing: > > > > > > [ 1473.912280] ================================= > > > [ 1473.913180] [ BUG: bad contention detected! ] > > > [ 1473.914071] 3.8.0-next-20130220-sasha-00038-g1ad55df-dirty #8 Tainted: G W > > > [ 1473.915684] --------------------------------- > > > [ 1473.916549] kworker/1:1/361 is trying to contend lock (&tty->ldisc_sem) at: > > > [ 1473.918031] [<ffffffff81c493df>] tty_ldisc_ref+0x1f/0x60 > > > [ 1473.919060] but there are no locks held! > > > > Ahh, of course. That explains why the rwsem trylock doesn't track lock > > stats -- because by the time lock_contended() is called, up_write() > > could have just called lockdep_release(), so that it appears as if the > > lock has been released when in fact it has not but is about to. > > > > I'll just remove the lock contention test from the trylocks. Hi Greg, I thought I'd recap the various reports so this patchset can move forward and you don't feel like you're wasting time reviewing it. 1. The 'BUG: bad contention detected' is fixed by the inline patch I replied with. 2. The various hung task reports specifically wrt. pmtx_open() and tty_open() actually pre-date this series and have been discovered to be due to the ircomm_tty driver sleeping holding the tty_lock(). Dave Miller has that patch and may or may not apply it. [You were cc'd on that conversation.] 3. The other hung task reports from Sasha involving hangup are only indirectly related to this patchset, in that the task signalling done by the session leader is in the wrong order wrt. the ldisc hangup. Sasha and I have been running an additional patchset on top of this which properly orders the foreground process group signalling and fixes that hung task. I've delayed rebasing this on tty-next (which will now be necessary because of the last-minute drop of the "tty is NULL" warning) until after this review is complete. Please let me know if you have concerns I haven't addressed here. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
