From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Zachary Amsden <zach@vmware.com>
Cc: Linus Torvalds <torvalds@osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>, Chris Wright <chrisw@sous-sol.org>,
stable@kernel.org, Rusty Russell <rusty@rustcorp.com.au>,
Virtualization Mailing List <virtualization@lists.osdl.org>,
Andi Kleen <ak@suse.de>
Subject: Re: [PATCH] Fix preemptible lazy mode bug
Date: Thu, 23 Aug 2007 23:53:29 -0700 [thread overview]
Message-ID: <46CE8069.9070404@goop.org> (raw)
In-Reply-To: <46CE70C8.2030005@vmware.com>
Zachary Amsden wrote:
> I recently sent off a fix for lazy vmalloc faults which can happen
> under paravirt when lazy mode is enabled. Unfortunately, I jumped the
> gun a bit on fixing this. I neglected to notice that since the new
> call to flush the MMU update queue is called from the page fault
> handler, it can be pre-empted. Both VMI and Xen use per-cpu variables
> to track lazy mode state, as all previous calls to set, disable, or
> flush lazy mode happened from a non-preemptable state.
Hm. Doing any kind of lazy-state operation with preemption enabled is
fundamentally meaningless. How does it get into a preemptable state
with a lazy mode enabled now? If a sequence of code with preempt
disabled touches a missing vmalloc mapping, it gets a fault to fix up
the mapping, and the fault handler can end up preempting the thread?
That sounds like a larger bug than just paravirt lazy mode problems.
J
next prev parent reply other threads:[~2007-08-24 6:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-24 5:46 [PATCH] Fix preemptible lazy mode bug Zachary Amsden
2007-08-24 6:53 ` Jeremy Fitzhardinge [this message]
2007-08-24 6:59 ` Zachary Amsden
2007-08-25 11:57 ` Rusty Russell
2007-09-01 21:09 ` Jeremy Fitzhardinge
2007-09-01 21:09 ` Jeremy Fitzhardinge
2007-09-03 20:14 ` Rusty Russell
2007-09-04 13:42 ` Jeremy Fitzhardinge
2007-09-05 16:33 ` Rusty Russell
2007-09-05 17:05 ` Zachary Amsden
2007-09-05 17:48 ` Rusty Russell
2007-09-05 20:10 ` Jeremy Fitzhardinge
2007-09-05 20:37 ` Rusty Russell
2007-09-05 23:49 ` Zachary Amsden
2007-09-06 5:41 ` Andi Kleen
2007-09-06 9:56 ` Jeremy Fitzhardinge
2007-09-06 9:57 ` Jeremy Fitzhardinge
-- strict thread matches above, loose matches on Subject: below --
2007-08-24 5:46 Zachary Amsden
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=46CE8069.9070404@goop.org \
--to=jeremy@goop.org \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=chrisw@sous-sol.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=stable@kernel.org \
--cc=torvalds@osdl.org \
--cc=virtualization@lists.osdl.org \
--cc=zach@vmware.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.