[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1001261357390.3574@localhost.localdomain>
Date: Tue, 26 Jan 2010 14:11:28 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
cc: Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
stable@...nel.org, stable-review@...nel.org,
akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
Al Viro <viro@...IV.linux.org.uk>,
Tavis Ormandy <taviso@...gle.com>,
Jeff Dike <jdike@...toit.com>, Julien Tinnes <jln@...gle.com>,
Matt Mackall <mpm@...enic.com>
Subject: Re: [06/11] tty: fix race in tty_fasync
On Tue, 26 Jan 2010, Eric W. Biederman wrote:
> Greg KH <gregkh@...e.de> writes:
>
> > 2.6.27-stable review patch. If anyone has any objections, please let us know.
>
> Only that __f_setown by way of f_modown unconditionally enables interrupts. So
> without touching f_modown as well in mainline we have nasty sounding lockdep warnings.
Hmm. That seems to be true in mainline too, isn't it?
So now we have:
- tty_fasync() gets tty->ctrl_lock, with spin_lock_irqsave()
- it then calls __f_setown()
- which calls f_modown(),
- which does
write_lock_irq(&filp->f_owner.lock);
..
write_unlock_irq(&filp->f_owner.lock);
which in turn enables interrupts while we still hold ctrl_lock.
so that whole commit 70362511806 was/is buggy in mainline too.
The minimal fix is likely to just make f_modown() use
write_lock_irqsave/restore. Greg?
Linus
--
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/
Powered by blists - more mailing lists