From: Suresh Siddha <suresh.b.siddha@intel.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>,
"Simon Holm Thøgersen" <odie@cs.aau.dk>,
"Vegard Nossum" <vegard.nossum@gmail.com>,
"Patrick McHardy" <kaber@trash.net>,
"Linux Kernel Mailinglist" <linux-kernel@vger.kernel.org>,
"Chuck Ebbert" <cebbert@redhat.com>,
"x86@kernel.org" <x86@kernel.org>
Subject: Re: 2.6.26-git: NULL pointer deref in __switch_to
Date: Tue, 17 Jun 2008 23:23:57 -0700 [thread overview]
Message-ID: <20080618062357.GC23370@linux-os.sc.intel.com> (raw)
In-Reply-To: <200806181534.24085.rusty@rustcorp.com.au>
hi Rusty,
On Tue, Jun 17, 2008 at 10:34:23PM -0700, Rusty Russell wrote:
> Firstly, thanks for figuring this out. But math_state_restore() has nasty
> semantics now. Currently lguest will work, because no code path following
> this call relies on being on the same CPU.
>
> So, this patch is fine, but I wonder if I should just be forcing fpu
> allocation earlier for lguest tasks, so I can avoid this altogether?
Even with force fpu allocation, we need these fixes(except for the SYSENTER
hunk)
Just to clarify, dynamic fpu allocation didn't create these problems.
Some of these problems were there before aswell, and would show up as
fpu corruption for some of the tasks inside the lguest. With the
dynamic fpu allocation, it showed up as host kernel oops.
In future, if lguest driver code ever has a code path which relies
on running on the same cpu after math_state_restore(), yes they
can force allocate, by doing early math_state_restore() before
the guest starts.
But the current usage of lguest_set_ts() is clearly broken and violates
certain behavior expected by the fpu context switch handling routines.
thanks,
suresh
next prev parent reply other threads:[~2008-06-18 6:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-13 17:42 2.6.26-git: NULL pointer deref in __switch_to Patrick McHardy
2008-06-13 18:24 ` Vegard Nossum
2008-06-13 22:47 ` Suresh Siddha
2008-06-14 6:20 ` Ingo Molnar
2008-06-14 7:39 ` Patrick McHardy
2008-06-16 11:06 ` Jens Axboe
2008-06-14 7:36 ` Patrick McHardy
2008-06-16 10:15 ` Simon Holm Thøgersen
2008-06-16 10:29 ` Patrick McHardy
2008-06-16 12:10 ` Patrick McHardy
2008-06-16 17:49 ` Suresh Siddha
2008-06-16 21:21 ` Simon Holm Thøgersen
2008-06-17 23:50 ` Suresh Siddha
2008-06-18 5:34 ` Rusty Russell
2008-06-18 6:23 ` Suresh Siddha [this message]
2008-06-18 12:19 ` Rusty Russell
2008-06-18 8:42 ` Patrick McHardy
2008-06-18 13:57 ` Simon Holm Thøgersen
2008-06-13 20:10 ` Rafael J. Wysocki
2008-06-14 7:33 ` Patrick McHardy
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=20080618062357.GC23370@linux-os.sc.intel.com \
--to=suresh.b.siddha@intel.com \
--cc=cebbert@redhat.com \
--cc=kaber@trash.net \
--cc=linux-kernel@vger.kernel.org \
--cc=odie@cs.aau.dk \
--cc=rusty@rustcorp.com.au \
--cc=vegard.nossum@gmail.com \
--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