2.6.0 oops

[Anton Blanchard]

Hi,

Running bash-shared-mappings on ameslab BK from last night I got the
following oops:

cpu 0: Vector: 300 (Data Access) at [c00000000ee63760]
    pc: c00000000000e158 (.__hash_page+0x2c/0xa4)
    lr: c00000000004af14 (.update_mmu_cache+0x15c/0x1d4)
    sp: c00000000ee639e0
   msr: a000000000009032
   dar: 0
 dsisr: 40000000
  current = 0xc000000001e18300
  paca    = 0xc00000000051a000
    pid   = 17778, comm = init
0:mon> t
c00000000ee63ae0  c00000000004af14  .update_mmu_cache+0x15c/0x1d4
c00000000ee63b90  c00000000008fe40  .do_no_page+0x288/0x554
c00000000ee63c60  c0000000000903c8  .handle_mm_fault+0x194/0x268
c00000000ee63d00  c000000000049734  .do_page_fault+0x160/0x48c
c00000000ee63e30  c00000000000acb0  InstructionAccess_common+0x10c/0x110

0:mon> di %pc
c00000000000e158  7fe030a8      ldarx   r31,r0,r6

We died nice and early in __hash_page, all arguments should be preserved:

int __hash_page(unsigned long ea, unsigned long access, unsigned long vsid,
		pte_t *ptep, unsigned long trap, int local);

R03 = 000000000ff4e7d8
R04 = 0000000000000003
R05 = 0000000e3779b970
R06 = 0000000000000000
R07 = 0000000000000300
R08 = 0000000000000000

ea is probably somewhere in shared libraries. access is read/write,
vsid looks ok but ptep is NULL. How did this happen? We hold the page
table spinlock around the whole region that does the set_pte in
do_no_page right through to update_mmu_cache where we died. So Im
guessing we did put a pte in there but why didnt find_linux_pte find it?

There are 2 ways find_linux_pte (in update_mmu_cache) could return NULL.
Either the pgd/pmd is empty or the pte doesnt have _PAGE_PRESENT set.
We did check that the pte had _PAGE_ACCESSED set earlier in update_mmu_cache
so its sounding like we are asking to insert a pte with _PAGE_ACCESSED set
and _PAGE_PRESENT not set.

The safe thing to do is add a check for NULL after find_linux_pte,
update_mmu_cache is just an optimisation and it makes sense to guard
against weird things like this. However I would like to understand how
we ended up in this scenario in the first place...

Anton

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/