[lkml]   [2011]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    Subject[082/104] x86/paravirt: PTE updates in k(un)map_atomic need to be synchronous, regardless of lazy_mmu mode
    3.1-stable review patch.  If anyone has any objections, please let me know.


    From: Konrad Rzeszutek Wilk <>

    commit 2cd1c8d4dc7ecca9e9431e2dabe41ae9c7d89e51 upstream.

    Fix an outstanding issue that has been reported since 2.6.37.
    Under a heavy loaded machine processing "fork()" calls could
    crash with:

    BUG: unable to handle kernel paging request at f573fc8c
    IP: [<c01abc54>] swap_count_continued+0x104/0x180
    *pdpt = 000000002a3b9027 *pde = 0000000001bed067 *pte = 0000000000000000 Oops: 0000 [#1] SMP
    Modules linked in:
    Pid: 1638, comm: apache2 Not tainted 3.0.4-linode37 #1
    EIP: 0061:[<c01abc54>] EFLAGS: 00210246 CPU: 3
    EIP is at swap_count_continued+0x104/0x180
    .. snip..
    Call Trace:
    [<c01ac222>] ? __swap_duplicate+0xc2/0x160
    [<c01040f7>] ? pte_mfn_to_pfn+0x87/0xe0
    [<c01ac2e4>] ? swap_duplicate+0x14/0x40
    [<c01a0a6b>] ? copy_pte_range+0x45b/0x500
    [<c01a0ca5>] ? copy_page_range+0x195/0x200
    [<c01328c6>] ? dup_mmap+0x1c6/0x2c0
    [<c0132cf8>] ? dup_mm+0xa8/0x130
    [<c013376a>] ? copy_process+0x98a/0xb30
    [<c013395f>] ? do_fork+0x4f/0x280
    [<c01573b3>] ? getnstimeofday+0x43/0x100
    [<c010f770>] ? sys_clone+0x30/0x40
    [<c06c048d>] ? ptregs_clone+0x15/0x48
    [<c06bfb71>] ? syscall_call+0x7/0xb

    The problem is that in copy_page_range() we turn lazy mode on,
    and then in swap_entry_free() we call swap_count_continued()
    which ends up in:

    map = kmap_atomic(page, KM_USER0) + offset;

    and then later we touch *map.

    Since we are running in batched mode (lazy) we don't actually
    set up the PTE mappings and the kmap_atomic is not done
    synchronously and ends up trying to dereference a page that has
    not been set.

    Looking at kmap_atomic_prot_pfn(), it uses
    'arch_flush_lazy_mmu_mode' and doing the same in
    kmap_atomic_prot() and __kunmap_atomic() makes the problem go

    Interestingly, commit b8bcfe997e4615 ("x86/paravirt: remove lazy
    mode in interrupts") removed part of this to fix an interrupt
    issue - but it went to far and did not consider this scenario.

    Signed-off-by: Konrad Rzeszutek Wilk <>
    Cc: Peter Zijlstra <>
    Cc: Jeremy Fitzhardinge <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Ingo Molnar <>
    Signed-off-by: Greg Kroah-Hartman <>

    arch/x86/mm/highmem_32.c | 2 ++
    1 file changed, 2 insertions(+)

    --- a/arch/x86/mm/highmem_32.c
    +++ b/arch/x86/mm/highmem_32.c
    @@ -45,6 +45,7 @@ void *kmap_atomic_prot(struct page *page
    vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
    set_pte(kmap_pte-idx, mk_pte(page, prot));
    + arch_flush_lazy_mmu_mode();

    return (void *)vaddr;
    @@ -88,6 +89,7 @@ void __kunmap_atomic(void *kvaddr)
    kpte_clear_flush(kmap_pte-idx, vaddr);
    + arch_flush_lazy_mmu_mode();
    else {

     \ /
      Last update: 2011-12-07 17:37    [W:0.021 / U:19.336 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site