L4android mlock on vectors page causes unresolvable page fault

Matthias Petschick matthias at sec.t-labs.tu-berlin.de
Fri Apr 5 10:10:21 CEST 2013


while experimenting with lvm, I noticed that mlocking the vectors page
at 0xbffff000 from user space causes an unresolvable page fault (see
full trace below). In particular, the lvcreate process attempts to lock
its mapped memory regions when activating a volume, which includes the
vectors page.

While debugging this, I further noticed that L4android maps the vectors
page to 0xbffff000 by default instead of 0xffff0000, configurable via
CONFIG_VECTORS_BASE, however references to the hard-coded address
0xffff0000 remain in some places under arch/l4, e.g. in
devicemaps_init() in arch/l4/mm/arch-arm/mmu.c. Without further
investigating how the vectors page addressing is treated in L4android, I
cannot say whether this is related or not.

The pc in the backtrace is in special_mapping_fault, apparently because
the vma for the vectors page was installed with a NULL pointer for its
pages array, hence vm_private_data is also NULL when dereferenced by
special_mapping_fault in if (*pages). The oops itself seems to be
triggered because pfa is 0x1 and l4x_handle_pagefault refuses to resolve
pagefaults for addresses < L4_PAGESIZE.

Here's the associated trace:
Page fault (non-resolved): pfa=1 pc=108df14
Internal error: Boom!: 410007 [#5] SMP
Modules linked in:
CPU: 0    Tainted: G      D W    (3.1.10-l4-dirty #8)
PC is at special_mapping_fault+0x80/0xe0
LR is at __do_fault+0x68/0x464
pc : [<0108df14>]    lr : [<01088b50>]    psr: 6000001f
sp : 132dbda8  ip : 00000000  fp : 0bd4eff8
r10: 00000000  r9 : 0137a1ac  r8 : 00000008
r7 : 00000000  r6 : bffff000  r5 : 0605ae20  r4 : 01d38288
r3 : 000bffff  r2 : 000bffff  r1 : 132dbdc8  r0 : 00000000
Flags: nZCv  IRQs on  FIQs on  Mode SYS_32  ISA ARM  Segment user
Process lvcreate (pid: 395, stack limit = 0x132da2f0)
Stack: (0x132dbda8 to 0x132dc000)
bda0:                   014e54a0 00000000 01d38288 01088b50 000284d0
bdc0: 132da000 01fa6700 00000008 000bffff bffff000 00000000 014a8e20
bde0: 01d38288 00000008 0bd4eff8 060d97fc 0605ae20 000bffff 00000000
be00: 000bffff 00000008 00000000 01600000 014c60e0 bffff000 0bd4c000
be20: 000005ff 0bd4eff8 01d38288 00000008 00000000 0108c138 0bd4eff8
be40: 00000052 01d38288 01fa6cc0 bffff000 0605ae20 132dbedc 0605ae20
be60: 132da000 00000000 00000001 00000010 00000000 00000000 014cf754
be80: 00000001 01d382a0 0605ae20 132dbedc 00000001 0605ae20 0605ae58
bea0: 00000052 00000000 00000000 132dbedc 0605ae5c 01d38288 c0000000
bec0: bffff000 0108d068 132dbedc 132da000 00001000 00000000 00000000
bee0: 0605ae5c 00000096 bffff000 0108d8f0 00001000 0000a790 000ed0d7
bf00: 132da000 0100f854 00001000 000ed0d7 00000000 00000000 00000000
bf20: 132da000 132dbfb0 01fa6cc0 132da000 014ec0e8 133ea36c 00000000
bf40: 00000000 00000000 00000000 00000000 00000000 01195d88 00000000
bf60: 00000000 00000000 00000000 00000000 01fa6cc0 01fa6cc0 b3000c00
bf80: b3000e00 ef000000 00000000 f1886fb8 ffff0200 60000010 0100d84c
bfa0: 000ed0b3 f1886fec 000ba4c8 00079560 bffff000 00001000 0000a790
bfc0: 00001000 000ed0d7 000bc08c 00000096 00000072 000ed0b3 000ad844
bfe0: 000bc0e0 bf87c608 00079560 40191234 60000010 bffff000 00000000
[<0108df14>] (special_mapping_fault+0x80/0xe0) from [<01088b50>]
[<01088b50>] (__do_fault+0x68/0x464) from [<0108bfb8>]
[<0108bfb8>] (handle_pte_fault+0xb0/0x1a0) from [<0108c138>]
[<0108c138>] (handle_mm_fault+0x90/0xc0) from [<0108c34c>]
[<0108c34c>] (__get_user_pages+0x12c/0x2f8) from [<0108cff4>]
[<0108cff4>] (__mlock_vma_pages_range.clone.2+0x78/0x80) from
[<0108d068>] (do_mlock_pages+0x6c/0x148)
[<0108d068>] (do_mlock_pages+0x6c/0x148) from [<0100f854>]
[<0100f854>] (l4x_vcpu_entry_c+0xc74/0x1f90) from [<00079560>] (0x79560)
Code: e1a02003 e1a0c003 e2400001 1afffff3 (e59c4000)
---[ end trace 47d173d365d03980 ]---
Segmentation fault

Maybe someone with a better understanding of how L4android treats the
vectors page has an idea what's going wrong here?



More information about the l4-hackers mailing list