From: Andrew Morton <akpm@linux-foundation.org>
To: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org,
linux-kernel@vger.kernel.org, Matt Mackall <mpm@selenic.com>
Subject: Re: 2.6.24-rc8-mm1: powerpc oopses
Date: Thu, 17 Jan 2008 14:51:05 -0800 [thread overview]
Message-ID: <20080117145105.ad968ea6.akpm@linux-foundation.org> (raw)
In-Reply-To: <200801172315.28129.m.kozlowski@tuxland.pl>
On Thu, 17 Jan 2008 23:15:27 +0100
Mariusz Kozlowski <m.kozlowski@tuxland.pl> wrote:
> Hello,
>
> The script below kills powerpc. oopses get longer and more
> wonderful with every next 'cated' file.
ppc32.
> /proc/<pid>/task/<pid>/pagemap seems to be the cause of oops. The
> important thing is that it oopses for random (that is not first in a row)
> process from /proc. So not every 'cat /proc/<pid>/task/<pid>/pagemap'
> causes an oops.
>
> I could try to bisect this but this powerpc box is iMac G3 (cpu at 400MHz)
> and this will take time. So any hints appreciated.
>
> Regards,
>
> Mariusz
>
> script:
> ---------
> #!/bin/bash
>
> for i in `find /proc/*/ -readable -type f`; do
> echo -n "cat $i > /dev/null ... ";
> logger -t proc_loop $i;
> sync;
> cat $i > /dev/null;
> echo "done";
> done
> ----------
> syslog:
> proc_loop: /proc/3731/task/3731/pagemap
> kernel: BUG: sleeping function called from invalid context at fs/proc/task_mmu.c:554
> kernel: in_atomic():1, irqs_disabled():0
> kernel: Call Trace:
> kernel: [cf1cddf0] [c000840c] show_stack+0x3c/0x194 (unreliable)
> kernel: [cf1cde20] [c002b2ec] __might_sleep+0xf4/0x108
> kernel: [cf1cde30] [c00d2d54] add_to_pagemap+0x40/0x11c
> kernel: [cf1cde50] [c00d2f44] pagemap_pte_range+0xa8/0x10c
> kernel: [cf1cde70] [c0081b30] walk_page_range+0x148/0x23c
> kernel: [cf1cdeb0] [c00d3104] pagemap_read+0x15c/0x244
> kernel: [cf1cdef0] [c0092144] vfs_read+0xc4/0x16c
> kernel: [cf1cdf10] [c009261c] sys_read+0x4c/0x90
> kernel: [cf1cdf40] [c001328c] ret_from_syscall+0x0/0x40
It's not really an oops - it's a warning. add_to_pagemap() is doing a
put_user() inside pagemap_pte_range->pte_offset_map->kmap_atomic.
A known bug, I'm afraid.
How to fix?
- double-buffer the data to be copied to userspace or
- take a local copy of the pte page then work on that instead or
- play copy_to_user_inatomic() tricks.
It would be really nice to get the maps4 stuff merged this time around but
it is looking unlikely.
> kernel: --- Exception: c01 at 0xff5a364
> kernel: LR = 0x10002f60
> kernel: BUG: scheduling while atomic: cat/8929/0x00000002
> kernel: Call Trace:
> kernel: [cf1cde90] [c000840c] show_stack+0x3c/0x194 (unreliable)
> kernel: [cf1cdec0] [c002db24] __schedule_bug+0x64/0x78
> kernel: [cf1cdee0] [c027207c] schedule+0x304/0x32c
> kernel: [cf1cdf40] [c0013a5c] recheck+0x0/0x28
> kernel: --- Exception: c01 at 0xff5a364
> kernel: LR = 0x10002f60
> kernel: BUG: scheduling while atomic: cat/8929/0x00000007
> kernel: Call Trace:
> kernel: [cf1cde90] [c000840c] show_stack+0x3c/0x194 (unreliable)
> kernel: [cf1cdec0] [c002db24] __schedule_bug+0x64/0x78
> kernel: [cf1cdee0] [c027207c] schedule+0x304/0x32c
> kernel: [cf1cdf40] [c0013a5c] recheck+0x0/0x28
> kernel: --- Exception: c01 at 0xff5a364
> kernel: LR = 0x10002f60
> kernel: BUG: scheduling while atomic: cat/8929/0x00000009
> kernel: Call Trace:
> kernel: [cf1cde90] [c000840c] show_stack+0x3c/0x194 (unreliable)
> kernel: [cf1cdec0] [c002db24] __schedule_bug+0x64/0x78
> kernel: [cf1cdee0] [c027207c] schedule+0x304/0x32c
> kernel: [cf1cdf40] [c0013a5c] recheck+0x0/0x28
> kernel: --- Exception: c01 at 0xff5a364
> kernel: LR = 0x10002f60
> kernel: Page fault in user mode with in_atomic() = 1 mm = cf2765a0
> kernel: NIP = ff0cbc8 MSR = 4000f932
> kernel: Oops: Weird page fault, sig: 11 [#3]
hm. Not sure how that happened. The arch code thinks we're running in
user mode.
> kernel: PREEMPT PowerMac
> kernel: Modules linked in: usbhid ide_cd_mod ohci_hcd usbcore uninorth_agp agpgart
> kernel: NIP: 0ff0cbc8 LR: 0ff0d398 CTR: 0ff0d2d0
> kernel: REGS: cf1cdf50 TRAP: 0401 Tainted: G D (2.6.24-rc8-mm1)
> kernel: MSR: 4000f932 <EE,PR,FP,ME,IR,DR> CR: 28022442 XER: 00000000
> kernel: TASK = cf8d74f0[8929] 'cat' THREAD: cf1cc000
> kernel: GPR00: 00000001 bf93e330 48029bf0 0ffed488 10016038 28022442 00000000 0ff5a364
> kernel: GPR08: 0000f932 00000000 00001032 00000000 28022442
> kernel: NIP [0ff0cbc8] 0xff0cbc8
> kernel: LR [0ff0d398] 0xff0d398
> proc_loop: /proc/3731/task/3731/wchan
> kernel: Call Trace:
> kernel: ---[ end trace 54bd1ed4883922c9 ]---
> kernel: note: cat[8929] exited with preempt_count 10
> proc_loop: /proc/3731/task/3731/oom_score
> proc_loop: /proc/3731/task/3731/oom_adj
> proc_loop: /proc/3731/fdinfo/0
> [... snip ...]
next prev parent reply other threads:[~2008-01-17 22:51 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080117023514.9df393cf.akpm@linux-foundation.org>
2008-01-17 18:18 ` 2.6.24-rc8-mm1: powerpc: include/asm/nvram.h:62: error: field 'partition' has incomplete type Mariusz Kozlowski
2008-01-17 19:27 ` Andrew Morton
2008-01-17 19:06 ` 2.6.24-rc8-mm1 powerpc build errors Olof Johansson
2008-01-17 19:35 ` Andrew Morton
2008-01-17 22:00 ` Greg KH
2008-01-17 22:15 ` 2.6.24-rc8-mm1: powerpc oopses Mariusz Kozlowski
2008-01-17 22:51 ` Andrew Morton [this message]
2008-01-17 23:39 ` Matt Mackall
2008-01-18 0:05 ` Andrew Morton
2008-01-18 0:12 ` Matt Mackall
2008-01-18 0:29 ` Andrew Morton
2008-01-18 0:47 ` Matt Mackall
2008-01-18 1:07 ` Andrew Morton
2008-01-18 1:16 ` Matt Mackall
2008-01-18 17:23 ` Mariusz Kozlowski
2008-01-18 17:33 ` Matt Mackall
2008-01-18 7:09 ` 2.6.24-rc8-mm1 build failure on headers_check Kamalesh Babulal
2008-01-18 7:38 ` Andrew Morton
2008-01-18 8:36 ` 2.6.24-rc8-mm1 Kernel oops will running kernbench Kamalesh Babulal
2008-01-18 8:44 ` Andrew Morton
2008-01-18 9:01 ` Paul Mackerras
2008-01-18 9:34 ` Kamalesh Babulal
2008-01-18 10:19 ` Paul Mackerras
2008-01-18 15:41 ` Milton Miller
2008-01-18 10:26 ` Paul Mackerras
2008-01-18 10:44 ` Kamalesh Babulal
2008-01-18 10:54 ` Balbir Singh
2008-01-25 6:05 ` 2.6.24 Kernel oops will running kernbench regression from 2.6.24-rc8-mm1 Kamalesh Babulal
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=20080117145105.ad968ea6.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=m.kozlowski@tuxland.pl \
--cc=mpm@selenic.com \
--cc=paulus@samba.org \
/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 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).