in_atomic() check in page_cache_get_speculative()

in_atomic() check in page_cache_get_speculative()

[Scott Wood]

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

Re: in_atomic() check in page_cache_get_speculative()

[Scott Wood]

[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

Re: in_atomic() check in page_cache_get_speculative()

[Benjamin Herrenschmidt]

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.