Bug 11234
Summary: | kernel is deadlocked due to tty->termios_mutex locked twice in one procedure | ||
---|---|---|---|
Product: | Drivers | Reporter: | kouyu (ckyoog) |
Component: | Console/Framebuffers | Assignee: | Alan (alan) |
Status: | CLOSED CODE_FIX | ||
Severity: | high | CC: | akpm |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.26 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: | Proposed fix |
Description
kouyu
2008-08-02 12:07:58 UTC
Now I remove mutex_lock(&vc->vc_tty->termios_mutex) and mutex_unlock in vc_resize in drivers/char/vt.c. And the programs, which need set a different window size in vt, work correctly. err, Alan? Erk everyone must be using tools that exercise the VT_RESIZE path only. Will sort that out Monday Oh my brain hurts It doesn't deadlock for me although we clearly take the mutex twice. I've got another report where someone is seeing races that can't occur here and the real fix is going to be foul. Seems we have a lack of sanity check on mutexes so that recursive mutex_lock *works* (but unlocks wrongly) if CONFIG_PREEMPT is set. So that explains why nobody found the bug and how to work around it for the moment. You mean setting CONFIG_PREEMPT to avoid this problem is a temporary method, don't you? I checked my kernel config just right now. That's right, I set CONFIG_PREEMPT_VOLUNTARY, not CONFIG_PREEMPT. I'll try that *method*, and tell you the result. Proposed patch follows. Its very ugly but will do for the short term and the code gets cleaned up in some further patches in testing for .28 Created attachment 17075 [details]
Proposed fix
Full fix turns out to be ghastly - sent Linus a partial revert to go back to the race condition. I've got a rework of this area lined up for -next and .28. Thank you Alan for response. I just tried set CONFIG_PREEMPT, and recompiled kernel, and the problem still existed. You mean this bug will be fixed in .28, and now I have to use that proposed patch only, don't you? Under discussion. Linus has said he'll look at it for 2.6.27 Short term fixes pushed upstream, longer term ones for 2.6.28 |