From: Jan Luebbe <jluebbe@lasnet.de>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, torvalds@linux-foundation.org
Subject: Re: [PATCH] fix console change race exposed by CFS
Date: Sun, 30 Sep 2007 10:31:05 +0200 [thread overview]
Message-ID: <1191141065.10375.9.camel@polaris> (raw)
In-Reply-To: <20070930072056.GA18108@elte.hu>
On Sun, 2007-09-30 at 09:20 +0200, Ingo Molnar wrote:
> * Jan Luebbe <jluebbe@lasnet.de> wrote:
> > From: Jan Lübbe <jluebbe@lasnet.de>
> >
> > The new behaviour of CFS exposes a race which occurs if a switch is
> > requested when vt_mode.mode is VT_PROCESS.
> >
> > The process with vc->vt_pid is signaled before vc->vt_newvt is set. This
> > causes the switch to fail when triggered by the monitoing process
> > because the target is still -1.
> >
> > Signed-off-by: Jan Lübbe <jluebbe@lasnet.de>
>
> nifty! I'm wondering what the symptoms of this bug were - how did you
> notice it? Also, i'm wondering how you managed to debug this - looks
> quite hard to trigger this race, right?
>
> Acked-by: Ingo Molnar <mingo@elte.hu>
>
> Ingo
I'm currenly porting the OpenMoko patchset to 2.6.23-rc8. We are using
psplash and kdrive. When booting, I got an error from psplash about
being unable to switch consoles. Strangely, it was possible to start
kdrive manually. So i set up qemu for kernel debugging, set some
interesting breakpoints and then saw that it was scheduling away
directly after the kill_pid. Then it was quite obvious.
It was triggering every time, on the device and in qemu identically.
Most people testing the RCs probably don't run psplash (or any other
program which sets vt_mode.mode to VT_PROCESS), so it wasn't noticed
earlier.
Jan
next prev parent reply other threads:[~2007-09-30 8:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-29 16:47 [PATCH] fix console change race exposed by CFS Jan Luebbe
2007-09-30 7:20 ` Ingo Molnar
2007-09-30 8:31 ` Jan Luebbe [this message]
2007-09-30 15:53 ` Ingo Molnar
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=1191141065.10375.9.camel@polaris \
--to=jluebbe@lasnet.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@linux-foundation.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