Hello,
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 01fa6cc0 bdc0: 132da000 01fa6700 00000008 000bffff bffff000 00000000 014a8e20 00000000 bde0: 01d38288 00000008 0bd4eff8 060d97fc 0605ae20 000bffff 00000000 0108bfb8 be00: 000bffff 00000008 00000000 01600000 014c60e0 bffff000 0bd4c000 0605ae20 be20: 000005ff 0bd4eff8 01d38288 00000008 00000000 0108c138 0bd4eff8 00000008 be40: 00000052 01d38288 01fa6cc0 bffff000 0605ae20 132dbedc 0605ae20 0108c34c be60: 132da000 00000000 00000001 00000010 00000000 00000000 014cf754 bffff000 be80: 00000001 01d382a0 0605ae20 132dbedc 00000001 0605ae20 0605ae58 0108cff4 bea0: 00000052 00000000 00000000 132dbedc 0605ae5c 01d38288 c0000000 c0000000 bec0: bffff000 0108d068 132dbedc 132da000 00001000 00000000 00000000 00000001 bee0: 0605ae5c 00000096 bffff000 0108d8f0 00001000 0000a790 000ed0d7 00001000 bf00: 132da000 0100f854 00001000 000ed0d7 00000000 00000000 00000000 40095068 bf20: 132da000 132dbfb0 01fa6cc0 132da000 014ec0e8 133ea36c 00000000 0bec6000 bf40: 00000000 00000000 00000000 00000000 00000000 01195d88 00000000 68732363 bf60: 00000000 00000000 00000000 00000000 01fa6cc0 01fa6cc0 b3000c00 132da000 bf80: b3000e00 ef000000 00000000 f1886fb8 ffff0200 60000010 0100d84c b3000c00 bfa0: 000ed0b3 f1886fec 000ba4c8 00079560 bffff000 00001000 0000a790 000c681c bfc0: 00001000 000ed0d7 000bc08c 00000096 00000072 000ed0b3 000ad844 000ba4c8 bfe0: 000bc0e0 bf87c608 00079560 40191234 60000010 bffff000 00000000 00000000 [<0108df14>] (special_mapping_fault+0x80/0xe0) from [<01088b50>] (__do_fault+0x68/0x464) [<01088b50>] (__do_fault+0x68/0x464) from [<0108bfb8>] (handle_pte_fault+0xb0/0x1a0) [<0108bfb8>] (handle_pte_fault+0xb0/0x1a0) from [<0108c138>] (handle_mm_fault+0x90/0xc0) [<0108c138>] (handle_mm_fault+0x90/0xc0) from [<0108c34c>] (__get_user_pages+0x12c/0x2f8) [<0108c34c>] (__get_user_pages+0x12c/0x2f8) from [<0108cff4>] (__mlock_vma_pages_range.clone.2+0x78/0x80) [<0108cff4>] (__mlock_vma_pages_range.clone.2+0x78/0x80) from [<0108d068>] (do_mlock_pages+0x6c/0x148) [<0108d068>] (do_mlock_pages+0x6c/0x148) from [<0100f854>] (l4x_vcpu_entry_c+0xc74/0x1f90) [<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?
Cheers,
Matthias
Hi,
On Fri Apr 05, 2013 at 10:10:21 +0200, Matthias Petschick wrote:
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.
Thanks for the report. I tried with the following:
#include <sys/mman.h> int main(void) { mlockall(MCL_CURRENT); return 0; }
at it just works for me. Does it also work in your setup?
Adam
Hey,
On 04/08/2013 12:05 AM, Adam Lackorzynski wrote:
Hi,
On Fri Apr 05, 2013 at 10:10:21 +0200, Matthias Petschick wrote:
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.
Thanks for the report. I tried with the following:
#include <sys/mman.h> int main(void) { mlockall(MCL_CURRENT); return 0; }
at it just works for me. Does it also work in your setup?
I can't test it right now but without looking too deep, I predict that it will work because mlockall calls
do_mlock_pages(0, TASK_SIZE, 1);
and TASK_SIZE is 0xbfc00000 for arch/l4, hence the vectors page should not be touched by it. Will nevertheless give it a shot tomorrow in case I missed something.
However, for completeness sake I can confirm that
#include <sys/mman.h> { int ret; ret = mlock((const void *)0xbffff000, 4096); return 0; }
triggers the exception for me.
- Matthias
On 04/08/2013 01:50 AM, Matthias Petschick wrote:
I can't test it right now but without looking too deep, I predict that it will work because mlockall calls
do_mlock_pages(0, TASK_SIZE, 1);
and TASK_SIZE is 0xbfc00000 for arch/l4, hence the vectors page should not be touched by it. Will nevertheless give it a shot tomorrow in case I missed something.
Yes, works as predicted. In case of lvm, the problem can of course be averted by either blacklisting the vectors page or configuring it to use mlockall. I can't say if the way mlock ungracefully handles attempts to lock the vectors page has any further, not directly obvious implications though.
On Mon Apr 08, 2013 at 15:35:53 +0200, Matthias Petschick wrote:
On 04/08/2013 01:50 AM, Matthias Petschick wrote:
I can't test it right now but without looking too deep, I predict that it will work because mlockall calls
do_mlock_pages(0, TASK_SIZE, 1);
and TASK_SIZE is 0xbfc00000 for arch/l4, hence the vectors page should not be touched by it. Will nevertheless give it a shot tomorrow in case I missed something.
Yes, works as predicted. In case of lvm, the problem can of course be averted by either blacklisting the vectors page or configuring it to use mlockall. I can't say if the way mlock ungracefully handles attempts to lock the vectors page has any further, not directly obvious implications though.
In your version the fix could be to use CONFIG_VECTORS_BASE instead of 0xffff0000 for install_special_mapping in process.c. Recent versions do not have this code anymore so it's just a guess.
Adam
l4-hackers@os.inf.tu-dresden.de
-
Adam Lackorzynski -
Matthias Petschick