Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753371AbdLHNTL (ORCPT ); Fri, 8 Dec 2017 08:19:11 -0500 Received: from mail-qt0-f193.google.com ([209.85.216.193]:38869 "EHLO mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752883AbdLHNTI (ORCPT ); Fri, 8 Dec 2017 08:19:08 -0500 X-Google-Smtp-Source: AGs4zMbII21sPe/YE1MNN1KaQNQ0lAmKgsqgP8on8BS7NXcueX4b2jCQZ+VDNATm8LgSSZ2mEQmsro/1v8PI+5XKXmE= MIME-Version: 1.0 In-Reply-To: References: <1512576648.26816.3.camel@primarydata.com> From: Geert Uytterhoeven Date: Fri, 8 Dec 2017 14:19:07 +0100 X-Google-Sender-Auth: ExKGD3eDSKCGt777N9ucj2poVtE Message-ID: Subject: Re: NFS crash, hashed pointers in backtrace To: Trond Myklebust Cc: "anna.schumaker@netapp.com" , "linux-kernel@vger.kernel.org" , "linux-renesas-soc@vger.kernel.org" , "linux-nfs@vger.kernel.org" , "me@tobin.cc" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2404 Lines: 65 On Wed, Dec 6, 2017 at 5:19 PM, Geert Uytterhoeven wrote: > On Wed, Dec 6, 2017 at 5:10 PM, Trond Myklebust wrote: >> On Wed, 2017-12-06 at 15:31 +0100, Geert Uytterhoeven wrote: >>> On Tue, Dec 5, 2017 at 5:02 PM, Geert Uytterhoeven >> org> wrote: >>> Got another nfsroot crash: >>> >>> Unable to handle kernel NULL pointer dereference at virtual address >>> 00000030 >>> pgd = 329e8f6e >>> [00000030] *pgd=80000040004003, *pmd=00000000 >>> Internal error: Oops: 206 [#1] SMP ARM >>> Modules linked in: >>> CPU: 0 PID: 101 Comm: kworker/u4:1 Not tainted >>> 4.15.0-rc2-koelsch-01166-g047d7d3248e08fc7-dirty #3762 >>> Hardware name: Generic R-Car Gen2 (Flattened Device Tree) >>> Workqueue: writeback wb_workfn (flush-0:15) >>> task: 8a5bf858 task.stack: e93c92bc >>> PC is at nfs_page_async_flush+0x110/0x244 > >>> static int nfs_page_async_flush(struct nfs_pageio_descriptor *pgio, >>> struct page *page) >>> { >>> struct nfs_page *req; >>> int ret = 0; >>> >>> ... >>> >>> /* If there is a fatal error that covers this write, just >>> exit */ >>> if (nfs_error_is_fatal_on_server(req->wb_context->error)) >>> goto out_launder; >>> >>> c03bc644: e595300c ldr r3, [r5, #12] >>> c03bc648: e5930030 ldr r0, [r3, #48] ; 0x30 >>> c03bc64c: ebfffd1b bl c03bbac0 >>> >>> >>> req->wb_context must be NULL. >> >> I'm confused. If your test involves only writing to a sysfs file, then >> why is the NFS code involved at all? > > I don't think the second was related to sysfs. > >> Could this be a use-after-free? > > Possibly. I'm seeing other crashes, too. Looking into them... Found it: https://lkml.org/lkml/2017/12/8/399 That one caused corruption (zeroing) of the 4th 32-bit word of a memory block, which is consistent with the "ldr r3, [r5, #12]" loading NULL above. So NFS is fine (as usual ;-), sorry for the fuzz... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds