Re: [-mm] BUG: sleeping function called from invalid context at include/linux/pagemap.h:290

KOSAKI Motohiro
2008-07-04T05:40:29Z

> > > Could you explain detail of reproduce way?
> >
> > Nothing special. I booted the system up, and entered KDE, and opened xterm,
> > and typed "dmesg".
> >
> > .config attached.
>
> The reason you're seeing it and others not is because your
> CONFIG_HIGHPTE=y
> is making the issue visible.
>
> __munlock_pte_handler is trying to lock_page (or migration_entry_wait)
> while using the per-cpu kmap_atomic from walk_pte_range's pte_offset_map.
> Sleeping functions called from atomic context.
>
> There's quite a lot to worry about there.

Wow, this is obiously bug ;-)
IMHO, CONFIG_UNEVICTABLE was developed aiming at 64bit. (had depend on 64BIT ago)
So, noboy tested it long time on 32bit.

Yes, it is definitly bad.
I'll fix soon (hopefully).

> That page table walker was originally written to gather some info
> for /proc display, not to act upon the page table contents in any
> serious way. So it's just doing pte_offset_map when every(?) other
> page table walk would be required to pte_offset_map_lock. If it
> were doing pte_offset_map_lock, then lots more people would have
> seen the problem sooner.
>
> Does this usage need to pte_offset_map_lock? I think to the extent
> that it needs to lock_page, it needs to pte_offset_map_lock: both
> are because file truncation (or more commonly reclaim, but without
> looking into it too carefully, I dare say reclaim isn't a problem
> in this context) could interfere with page->mapping and pte at any
> instant.
>
> Conveniently, we have not one but two attempts at a generic page
> walker (sigh!): the other one, apply_to_page_range in mm/memory.c,
> does do the lock; it also allocates a page table if it's not there,
> I guess that aspect wouldn't be a problem on an mlocked area. Maybe
> using apply_to_page_range would be better here, and sidestep the
> issue of not having CONFIG_PAGE_WALKER.
>
> But if it does pte_offset_map_lock, look, migration_entry_wait does
> so too; well, never mind the lock, it'll kunmap_atomic
> Obviously that part cries out for refactoring.
>
> And how do you manage the lock_page? Offhand, I don't know, I'm
> just reporting on the obvious. Would trylocking be good enough?
>
> (I do dislike "generic page walkers" because they encourage this
> kind of oversight; and I hate to think of the latency problems
> they might be introducing - no sign of a cond_resched in either.)

Thank you great explain.
but we can't use trylock because munlock should turn off PAGE_MLOCK at that time.

__munlock_pte_handler introduced for avoid PROT_NONE problem.
(get_user_pages() can't get PROT_NONE page, old implementation can't munlock PROT_NONE page)

So, We had 2 choice
1. enhance get_use_pages()
2. use pagewalk

current implementation select 2.
Unfortunately this is problematic choice.
Now, We have problem on CONFIG_HIGHPTE and !CONFIG_MMU environment.

So, I am gradually charmed by choice 1.
my fix plan is below

1. CONFIG_UNEVICTABLE depend on 64BIT (just temporary hotfix)
2. add vm_flags ignoring option to get_user_pages()
3. rewrite __munlock_vma_pages_range by new get_user_pages()
4. revert 1
5. revert pagewalker's Kconfig change (someone dislike "select" expression)

and Step1 patch is attached below.
this patch solve this problem temporary.

Li-san, Could you try to below patch on your environment?

----------------------
pagewalk use pte_offset_map().
pte_offset_map() use kmap_atomic().
__munlock_pte_handler() use lock_page().

So, in CONFIG_HIGHPTE=y, following error happend.

BUG: sleeping function called from invalid context at include/linux/pagemap.h:290
in_atomic():1, irqs_disabled():0
no locks held by gpg-agent/2134.
Pid: 2134, comm: gpg-agent Not tainted 2.6.26-rc8-mm1 #11
[<c0421d38>] __might_sleep+0xbe/0xc5
[<c04770a2>] __munlock_pte_handler+0x3c/0x9e
[<c047c11f>] walk_page_range+0x15b/0x1b4
[<c0477048>] __munlock_vma_pages_range+0x4e/0x5b
[<c0476f0c>] ? __munlock_pmd_handler+0x0/0x10
[<c0477066>] ? __munlock_pte_handler+0x0/0x9e
[<c0477064>] munlock_vma_pages_range+0xf/0x11
[<c0477dcb>] exit_mmap+0x32/0xf2
[<c042ac12>] ? exit_mm+0xc7/0xda
[<c042732a>] mmput+0x3a/0x8b
[<c042ac20>] exit_mm+0xd5/0xda
[<c042bf6a>] do_exit+0x1fb/0x5d5
[<c045c4df>] ? audit_syscall_exit+0x2aa/0x2c5
[<c042c3a3>] do_group_exit+0x5f/0x88
[<c042c3db>] sys_exit_group+0xf/0x11
[<c0403956>] syscall_call+0x7/0xb

then, this feature should be disabled on 32BIT until fixed above problem.

Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>

---
mm/Kconfig | 1 +
1 file changed, 1 insertion(+)

Index: b/mm/Kconfig
===================================================================
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -216,6 +216,7 @@ config PAGE_WALKER
config UNEVICTABLE_LRU
bool "Add LRU list to track non-evictable pages"
default y
+ depends on 64BIT
select PAGE_WALKER
help
Keeps unevictable pages off of the active and inactive pageout