From: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Greg Kroah-Hartman <gregkh@suse.de>
Subject: Re: v2.6.31-rc6: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
Date: Thu, 27 Aug 2009 17:15:34 +0800 [thread overview]
Message-ID: <1251364534.2606.16.camel@ymzhang> (raw)
In-Reply-To: <alpine.LFD.2.01.0908241655370.3824@localhost.localdomain>
On Mon, 2009-08-24 at 17:09 -0700, Linus Torvalds wrote:
>
> On Mon, 24 Aug 2009, Linus Torvalds wrote:
> >
> > But I wanted to let people know that the patch is clearly not the "last
> > word" on this. It's a useful thing to try, but we need something better.
>
> This may be better (this is a replacement for the previous patch).
>
> Instead of using 'cancel_delayed_work_sync()', it makes tty_ldisc_hangup()
> do a 'flush_scheduled_work()' afterwards, like the other callers already
> do.
>
> And like 'tty_ldisc_release()' already does, it does this all before even
> getting the ldisc_mutex, avoiding the deadlock.
>
> I'm not 100% happy with this patch either, but my remaining unhappiness is
> more with the tty locking in general that causes this all. I suspect this
> patch in itself is not any worse than the other hacks we have.
>
> Oh, and in case you didn't guess - this is _STILL_ totally untested. It
> compiles for me, but that's all I'm going to guarantee. I'm just looking
> at the code (and getting pretty fed up with it ;)
>
> And as already mentioned: I doubt the deadlock on tty->ldisc_mutex is
> anything that would be hit in practice. And even if it can be triggered,
> the previous patch I sent out is still interesting in a "does it make the
> problem go away" sense. Because if it doesn't (with or without a new
> deadlock), then I'm looking at all the wrong places.
>
> Linus
>
I traced kernel and the root cause is really that the process doesn't wait for
the work to be complete. So a new process picks up the released tty/work to
use it. After the new process deletes the timer but before releasing the tty,
the old scheduled work is started to add timer. Then, the new process releases
the tty struct, including work/timer. So later on when the timer rearmed by the old
scheduled work expires, kernel panic.
> ---
> drivers/char/tty_ldisc.c | 10 +++++++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/char/tty_ldisc.c b/drivers/char/tty_ldisc.c
> index 1733d34..f893d18 100644
> --- a/drivers/char/tty_ldisc.c
> +++ b/drivers/char/tty_ldisc.c
> @@ -508,8 +508,9 @@ static void tty_ldisc_restore(struct tty_struct *tty, struct tty_ldisc *old)
> * be obtained while the delayed work queue halt ensures that no more
> * data is fed to the ldisc.
> *
> - * In order to wait for any existing references to complete see
> - * tty_ldisc_wait_idle.
> + * You need to do a 'flush_scheduled_work()' (outside the ldisc_mutex
> + * in order to make sure any currently executing ldisc work is also
> + * flushed.
> */
>
> static int tty_ldisc_halt(struct tty_struct *tty)
> @@ -753,11 +754,14 @@ void tty_ldisc_hangup(struct tty_struct *tty)
> * N_TTY.
> */
> if (tty->driver->flags & TTY_DRIVER_RESET_TERMIOS) {
> + /* Make sure the old ldisc is quiescent */
> + tty_ldisc_halt(tty);
> + flush_scheduled_work();
Perhaps it's better with below:
int ret = tty_ldisc_halt(tty);
if (!ret)
flush_scheduled_work();
prev parent reply other threads:[~2009-08-27 9:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-20 5:46 v2.6.31-rc6: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 Eric W. Biederman
2009-08-20 6:07 ` Eric W. Biederman
[not found] ` <7b6bb4a50908200010h1c60d007p4fa017fd97c87c19@mail.gmail.com>
2009-08-20 7:33 ` Eric W. Biederman
2009-08-20 9:23 ` Xiaotian Feng
2009-08-21 2:09 ` Zhang, Yanmin
2009-08-21 18:23 ` Eric W. Biederman
2009-08-20 7:54 ` Dave Young
2009-08-20 8:00 ` Eric W. Biederman
2009-08-20 8:19 ` Dave Young
2009-08-24 22:34 ` Linus Torvalds
2009-08-24 23:51 ` Linus Torvalds
2009-08-25 0:09 ` Linus Torvalds
2009-08-25 1:41 ` Eric W. Biederman
2009-08-25 2:48 ` Dave Young
2009-08-25 3:08 ` Xiaotian Feng
2009-08-25 6:16 ` Zhang, Yanmin
2009-08-25 3:39 ` Frederic Weisbecker
2009-08-25 4:10 ` Linus Torvalds
2009-08-25 4:30 ` Linus Torvalds
2009-08-25 15:05 ` Frederic Weisbecker
2009-08-25 14:24 ` Frederic Weisbecker
2009-08-27 9:15 ` Zhang, Yanmin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1251364534.2606.16.camel@ymzhang \
--to=yanmin_zhang@linux.intel.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=ebiederm@xmission.com \
--cc=gregkh@suse.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox