* in_atomic() check in page_cache_get_speculative()
@ 2010-10-04 20:22 Scott Wood
2010-10-04 20:37 ` Scott Wood
0 siblings, 1 reply; 3+ messages in thread
From: Scott Wood @ 2010-10-04 20:22 UTC (permalink / raw)
To: Nick Piggin, linuxppc-dev
I'm seeing the in_atomic() check in page_cache_get_speculative()
(linux/pagemap.h:138) fail when running e500 KVM with . It's coming
from get_user_pages_fast(), from KVM's hva_to_pfn(). This is on kvm.git
plus a few local patches that should be completely unrelated, but it
looks like this code hasn't changed much in a couple years.
Interrupts are disabled by get_user_pages_fast(), but apparently
preemption was not separately disabled. The comment in
page_cache_get_speculative() says that preemption disabling is done by
rcu_read_lock(), and that "this function must be called inside the same
rcu_read_lock() section as has been used to lookup the page in the
pagecache radix-tree (or page table)".
Where is this RCU lock supposed to be acquired? I don't see any RCU in
arch/powerpc/mm/gup.c. Is it buried in some macro or function call?
-Scott
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: in_atomic() check in page_cache_get_speculative()
2010-10-04 20:22 in_atomic() check in page_cache_get_speculative() Scott Wood
@ 2010-10-04 20:37 ` Scott Wood
2010-10-08 1:31 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 3+ messages in thread
From: Scott Wood @ 2010-10-04 20:37 UTC (permalink / raw)
To: Nick Piggin, linuxppc-dev
[Updated with Nick's current address; previous one bounced]
On Mon, 4 Oct 2010 15:22:59 -0500
Scott Wood <scottwood@freescale.com> wrote:
> I'm seeing the in_atomic() check in page_cache_get_speculative()
> (linux/pagemap.h:138) fail when running e500 KVM with .
Sorry, that should finish as "with CONFIG_DEBUG_VM."
> It's coming
> from get_user_pages_fast(), from KVM's hva_to_pfn(). This is on kvm.git
> plus a few local patches that should be completely unrelated, but it
> looks like this code hasn't changed much in a couple years.
>
> Interrupts are disabled by get_user_pages_fast(), but apparently
> preemption was not separately disabled. The comment in
> page_cache_get_speculative() says that preemption disabling is done by
> rcu_read_lock(), and that "this function must be called inside the same
> rcu_read_lock() section as has been used to lookup the page in the
> pagecache radix-tree (or page table)".
>
> Where is this RCU lock supposed to be acquired? I don't see any RCU in
> arch/powerpc/mm/gup.c. Is it buried in some macro or function call?
>
> -Scott
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: in_atomic() check in page_cache_get_speculative()
2010-10-04 20:37 ` Scott Wood
@ 2010-10-08 1:31 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 3+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-08 1:31 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Nick Piggin
On Mon, 2010-10-04 at 15:37 -0500, Scott Wood wrote:
> [Updated with Nick's current address; previous one bounced]
>
> On Mon, 4 Oct 2010 15:22:59 -0500
> Scott Wood <scottwood@freescale.com> wrote:
>
> > I'm seeing the in_atomic() check in page_cache_get_speculative()
> > (linux/pagemap.h:138) fail when running e500 KVM with .
>
> Sorry, that should finish as "with CONFIG_DEBUG_VM."
>
> > It's coming
> > from get_user_pages_fast(), from KVM's hva_to_pfn(). This is on kvm.git
> > plus a few local patches that should be completely unrelated, but it
> > looks like this code hasn't changed much in a couple years.
> >
> > Interrupts are disabled by get_user_pages_fast(), but apparently
> > preemption was not separately disabled. The comment in
> > page_cache_get_speculative() says that preemption disabling is done by
> > rcu_read_lock(), and that "this function must be called inside the same
> > rcu_read_lock() section as has been used to lookup the page in the
> > pagecache radix-tree (or page table)".
> >
> > Where is this RCU lock supposed to be acquired? I don't see any RCU in
> > arch/powerpc/mm/gup.c. Is it buried in some macro or function call?
> >
Well, we shouldn't need the rcu lock if interrupts are off, at least
that's my understanding...
Cheers,
Ben.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-10-08 1:31 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-04 20:22 in_atomic() check in page_cache_get_speculative() Scott Wood
2010-10-04 20:37 ` Scott Wood
2010-10-08 1:31 ` Benjamin Herrenschmidt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).