From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752004AbbFXXzR (ORCPT ); Wed, 24 Jun 2015 19:55:17 -0400 Received: from mail.efficios.com ([78.47.125.74]:37263 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751014AbbFXXzG convert rfc822-to-8bit (ORCPT ); Wed, 24 Jun 2015 19:55:06 -0400 Date: Wed, 24 Jun 2015 23:54:56 +0000 (UTC) From: Mathieu Desnoyers To: Linus Torvalds Cc: Thomas Gleixner , Linux Kernel Mailing List , Ingo Molnar , "H. Peter Anvin" , the arch/x86 maintainers Message-ID: <1022548323.2631.1435190096462.JavaMail.zimbra@efficios.com> In-Reply-To: References: <1435162498-23082-1-git-send-email-mathieu.desnoyers@efficios.com> <609198255.2568.1435171747039.JavaMail.zimbra@efficios.com> Subject: Re: [RFC PATCH] Fix: x86 unaligned __memcpy to/from virtual memory MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Originating-IP: [78.47.125.74] X-Mailer: Zimbra 8.6.0_GA_1153 (ZimbraWebClient - FF38 (Linux)/8.6.0_GA_1153) Thread-Topic: x86 unaligned __memcpy to/from virtual memory Thread-Index: M+A0KgfyZAOBh8a/w5c0ZWhEsiUQ1Q== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Jun 24, 2015, at 3:15 PM, Linus Torvalds torvalds@linux-foundation.org wrote: > On Wed, Jun 24, 2015 at 11:49 AM, Mathieu Desnoyers > wrote: >> >> Here is the output. I added the printk just after the initial range >> check within vmalloc_fault. > > Good. Can you add printk's to the error return paths too, so that we > see which one it is that triggers. OK, see below. This time the fault occurred at an unaligned address. It fails on the !pte_present(*pte_ref) check. > > If it is a valid vmalloc address, then vmalloc_fault() _should_ just > fix it up and return 0. Clearly it doesn't, and hits one of the > "return -1" cases instead. > > In particular, that > > pgd_ref = pgd_offset_k(address); > > should return the reference page table pointer for init_mm, which is > what vmalloc() itself *should* be populating. > > The fact that it sounds like one of the "pud/pmd/pte_none()" checks > for the reference ends up returning true, seems to indicate that the > page tables haven't been filled in even for the reference address. > Which is really really odd. > > I'm really inclined to think that it's something in lttng, because > it's so odd. A race with vunmap() on another CPU? How could > vmalloc_fault() not see the reference page table contents? [ 69.719102] DEBUG: vmalloc_fault at address 0xffffc900077e0f3b [ 69.720216] DEBUG: !pte_present(*pte_ref) error [ 69.720216] BUG: unable to handle kernel paging request at ffffc900077e0f3b [ 69.720216] IP: [] __memcpy+0x12/0x20 [ 69.720216] PGD 236c92067 PUD 236c93067 PMD 22cc87067 PTE 0 [ 69.720216] Oops: 0000 [#1] SMP [ 69.720216] Modules linked in: lttng_probe_workqueue(O) lttng_probe_vmscan(O) lttng_probe_udp(O) lttng_probe_timer(O) lttng_probe_sunrpc(O) lttng_probe_statedump(O) lttng_probe_sock(O) lttng_probe_skb(O) lttng_probe_signal(O) lttng_probe_scsi(O) lttng_probe_sched(O) lttng_probe_regmap(O) lttng_probe_rcu(O) lttng_probe_random(O) lttng_probe_power(O) lttng_probe_net(O) lttng_probe_napi(O) lttng_probe_module(O) lttng_probe_kmem(O) lttng_probe_jbd2(O) lttng_probe_irq(O) lttng_probe_ext4(O) lttng_probe_compaction(O) lttng_probe_block(O) lttng_types(O) lttng_ring_buffer_metadata_mmap_client(O) lttng_ring_buffer_client_mmap_overwrite(O) lttng_ring_buffer_client_mmap_discard(O) lttng_ring_buffer_metadata_client(O) lttng_ring_buffer_client_overwrite(O) lttng_ring_buffer_client_discard(O) lttng_tracer(O) lttng_statedump(O) lttng_kprobes(O) lttng_lib_ring_buffer(O) lttng_kretprobes(O) virtio_net virtio_blk virtio_pci virtio_ring virtio [last unloaded: lttng_statedump] [ 69.720216] CPU: 12 PID: 3536 Comm: lttng-consumerd Tainted: G O 4.1.0+ #11 [ 69.720216] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [ 69.720216] task: ffff8800bab3b660 ti: ffff88023344c000 task.ti: ffff88023344c000 [ 69.720216] RIP: 0010:[] [] __memcpy+0x12/0x20 [ 69.720216] RSP: 0018:ffff88023344fda0 EFLAGS: 00010246 [ 69.720216] RAX: ffff880233135025 RBX: 0000000000000fd8 RCX: 00000000000001fb [ 69.720216] RDX: 0000000000000000 RSI: ffffc900077e0f3b RDI: ffff880233135025 [ 69.720216] RBP: ffff88023344fdb8 R08: ffff880037ae3a00 R09: 0000000000005000 [ 69.720216] R10: 0000000000000000 R11: 0000000000000246 R12: ffff88023344fdc8 [ 69.720216] R13: ffff8800bb33f000 R14: 0000000000000fd8 R15: 0000000000000fd8 [ 69.720216] FS: 00007fb2d28ae700(0000) GS:ffff880237380000(0000) knlGS:0000000000000000 [ 69.720216] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 69.720216] CR2: ffffc900077e0f3b CR3: 000000023329d000 CR4: 00000000000006e0 [ 69.720216] Stack: [ 69.720216] ffffffffa05a6797 ffff88023527ad00 ffff88023527ad50 ffff88023344fe48 [ 69.720216] ffffffffa046d060 ffff8800bb33f000 0000000000000000 0000000000000fd8 [ 69.720216] ffffffff00000001 ffff880037ae3a00 0000000000000fd8 0000000000005025 [ 69.720216] Call Trace: [ 69.720216] [] ? lttng_event_write+0x87/0xb0 [lttng_ring_buffer_metadata_client] [ 69.720216] [] lttng_metadata_output_channel+0xd0/0x120 [lttng_tracer] [ 69.720216] [] lttng_metadata_ring_buffer_ioctl+0x79/0xd0 [lttng_tracer] [ 69.720216] [] do_vfs_ioctl+0x2e0/0x4e0 [ 69.720216] [] ? file_has_perm+0x87/0xa0 [ 69.720216] [] SyS_ioctl+0x81/0xa0 [ 69.720216] [] ? syscall_trace_leave+0xd1/0xe0 [ 69.720216] [] tracesys_phase2+0x84/0x89 [ 69.720216] Code: 5b 5d c3 66 0f 1f 44 00 00 e8 6b fc ff ff eb e1 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 [ 69.720216] RIP [] __memcpy+0x12/0x20 [ 69.720216] RSP [ 69.720216] CR2: ffffc900077e0f3b [ 69.720216] ---[ end trace c35549bf8e0386a2 ]--- -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com