n_read+0x3c/0x54 []do_page_fault+0x114/0x5e8 []handle_page_fault+0xc/0x80 []perf_callchain+0x224/0x31c []perf_prepare_sample+0x240/0x2fc []__perf_event_overflow+0x280/0x398 []perf_swevent_overflow+0x9c/0x10c []perf_swevent_ctx_event+0x1d0/0x230 []do_perf_sw_event+0x84/0xe4 []perf_sw_event_context_switch+0x150/0x1b4 []perf_event_task_sched_out+0x44/0x2d4 []schedule+0x2c0/0x614 []__cond_resched+0x34/0x90 []_cond_resched+0x4c/0x68 []move_page_tables+0xb0/0x418 []setup_arg_pages+0x184/0x2a0 []load_elf_binary+0x394/0x1208 []search_binary_handler+0xe0/0x2c4 []do_execve+0x1bc/0x268 []sys_execve+0x84/0xc8 []ret_from_syscall+0x0/0x3c A page fault occurred walking the callchain while creating a perf sample for the context-switch event. To handle the page fault the mmap_sem is needed, but it is currently held by setup_arg_pages. (setup_arg_pages calls shift_arg_pages with the mmap_sem held. shift_arg_pages then calls move_page_tables which has a cond_resched at the top of its for loop - hitting that cond_resched is what caused the context switch.) This is an extension of Anton's proposed patch: https://lkml.org/lkml/2011/7/24/151 adding case for 32-bit ppc. Tested on the system that first generated the panic and then again with latest kernel using a PPC VM. I am not able to test the 64-bit path - I do not have H/W for it and 64-bit PPC VMs (qemu on Intel) is horribly slow. Signed-off-by: David Ahern Signed-off-by: Benjamin Herrenschmidt