linux-kernel - Re: MM kernels 2.6.24-rc*-mm*, 2.6.24-mm1: gnome-terminal stuck in tty

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 07 Feb 2008 21:24:47 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	"J. K. Cliburn" <jacliburn@...lsouth.net>,
	Zan Lynx <zlynx@....org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: MM kernels 2.6.24-rc*-mm*, 2.6.24-mm1: gnome-terminal stuck in
	tty_poll


On Thu, 2008-02-07 at 20:49 +0100, Peter Zijlstra wrote:
> On Wed, 2008-02-06 at 18:23 -0800, Andrew Morton wrote:
> > On Wed, 06 Feb 2008 20:10:50 -0600 "J. K. Cliburn" <jacliburn@...lsouth.net> wrote:
> > 
> > > Zan Lynx wrote:
> > > 
> > > > gnome-terminal gets stuck.
> > > 
> > > I began seeing this very thing around 2.6.24 time.  (Fedora 8, vanilla 
> > > kernel.)  I could usually cause the gnome terminal to hang if I rapidly 
> > > resized the window while executing make check-headers.

Weird, .24 proper doesn't have that patch. What exact fedora kernel was
that (so I can look at it).

> > > Over a couple of days I bisected it down to this commit:
> > > 
> > > Commit:     37bb6cb4097e29ffee970065b74499cbf10603a3
> > > Parent:     d3d74453c34f8fd87674a8cf5b8a327c68f22e99
> > > Author:     Peter Zijlstra <a.p.zijlstra@...llo.nl>
> > > AuthorDate: Fri Jan 25 21:08:32 2008 +0100
> > > Committer:  Ingo Molnar <mingo@...e.hu>
> > > CommitDate: Fri Jan 25 21:08:32 2008 +0100
> > > 
> > >      hrtimer: unlock hrtimer_wakeup
> > > 
> > >      hrtimer_wakeup creates a
> > > 
> > >        base->lock
> > >          rq->lock
> > > 
> > >      lock dependancy. Avoid this by switching to HRTIMER_CB_IRQSAFE_NO_SOFTIRQ
> > >      which doesn't hold base->lock.
> > > 
> > >      This fully untangles hrtimer locks from the scheduler locks, and allows
> > >      hrtimer usage in the scheduler proper.
> > > 
> > >      Signed-off-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> > >      Signed-off-by: Ingo Molnar <mingo@...e.hu>
> > > ---
> > >   kernel/hrtimer.c |    4 +++-
> > >   1 files changed, 3 insertions(+), 1 deletions(-)


Which is even weirder, because the provided trace indicates
schedule_timeout()
        
        Call Trace:
         [schedule_timeout+149/208] schedule_timeout+0x95/0xd0
         [<ffffffff8057dde5>] schedule_timeout+0x95/0xd0
         [tty_poll+145/160] tty_poll+0x91/0xa0
         [<ffffffff80430f11>] tty_poll+0x91/0xa0
         [do_sys_poll+617/880] do_sys_poll+0x269/0x370
         [<ffffffff802bbe69>] do_sys_poll+0x269/0x370
         [__pollwait+0/304] __pollwait+0x0/0x130
         [<ffffffff802bcb30>] __pollwait+0x0/0x130
        
[ weird trace format this ]

which uses the other timer API, and should not be affected by
hrtimer_wakeup().

/me puzzled...


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/