From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ECF62C432C0 for ; Mon, 2 Dec 2019 09:09:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 98B6A215E5 for ; Mon, 2 Dec 2019 09:09:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 98B6A215E5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 07B416B0003; Mon, 2 Dec 2019 04:09:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 02B7A6B0006; Mon, 2 Dec 2019 04:09:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E84B46B0007; Mon, 2 Dec 2019 04:09:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0007.hostedemail.com [216.40.44.7]) by kanga.kvack.org (Postfix) with ESMTP id D30C16B0003 for ; Mon, 2 Dec 2019 04:09:37 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 2D9BC181AC1F5 for ; Mon, 2 Dec 2019 09:09:37 +0000 (UTC) X-FDA: 76219628394.26.chalk76_70f1f6cacbe17 X-HE-Tag: chalk76_70f1f6cacbe17 X-Filterd-Recvd-Size: 5568 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Mon, 2 Dec 2019 09:09:36 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E36F9328; Mon, 2 Dec 2019 01:09:34 -0800 (PST) Received: from arm.com (e112269-lin.cambridge.arm.com [10.1.194.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DC1513F52E; Mon, 2 Dec 2019 01:09:29 -0800 (PST) Date: Mon, 2 Dec 2019 09:09:24 +0000 From: Steven Price To: Borislav Petkov Cc: Linus Torvalds , Andrew Morton , "alex@ghiti.fr" , "aou@eecs.berkeley.edu" , Ard Biesheuvel , Arnd Bergmann , Andrey Ryabinin , Benjamin Herrenschmidt , Christian Borntraeger , Qian Cai , Catalin Marinas , Dave Hansen , "dave.jiang@intel.com" , David Miller , Dmitry Vyukov , Alexander Potapenko , Vasily Gorbik , Heiko Carstens , Peter Anvin , James Morse , James Hogan , Kan Liang , Linux-MM , Russell King - ARM Linux , Andrew Lutomirski , Mark Rutland , "mawilcox@microsoft.com" , Ingo Molnar , "mm-commits@vger.kernel.org" , Michael Ellerman , "n-horiguchi@ah.jp.nec.com" , Palmer Dabbelt , Paul Burton , Paul Walmsley , Paul Mackerras , Peter Zijlstra , "ralf@linux-mips.org" , "shashim@codeaurora.org" , Thomas Gleixner , "vgupta@synopsys.com" , Will Deacon , "zong.li@sifive.com" Subject: Re: [patch 064/158] mm: add generic ptdump Message-ID: <20191202090924.GA46592@arm.com> References: <20191201015304.cRPsmKUTM%akpm@linux-foundation.org> <20191201090724.GA6629@zn.tnic> <20191201151010.GC6629@zn.tnic> <20191201152119.GD6629@zn.tnic> <20191201154553.GE6629@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191201154553.GE6629@zn.tnic> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, Dec 01, 2019 at 03:45:54PM +0000, Borislav Petkov wrote: > On Sun, Dec 01, 2019 at 04:21:19PM +0100, Borislav Petkov wrote: > > On Sun, Dec 01, 2019 at 04:10:11PM +0100, Borislav Petkov wrote: > > > So lemme first confirm it really is caused by those patches. > > > > Yeah, those patches are causing it. Tried your current master - it is OK > > - and then applied Andrew's patches I was CCed on, ontop, and I got in a > > VM: > > > > VFS: Mounted root (ext4 filesystem) readonly on device 8:2. > > devtmpfs: mounted > > Freeing unused kernel image (initmem) memory: 664K > > Write protecting kernel text and read-only data: 18164k > > NX-protecting the kernel data: 7416k > > BUG: kernel NULL pointer dereference, address: 00000014 > > #PF: supervisor read access in kernel mode > > #PF: error_code(0x0000) - not-present page > > *pdpt = 0000000000000000 *pde = f000ff53f000ff53 > > Oops: 0000 [#1] PREEMPT SMP PTI > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0+ #3 > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1 04/01/2014 > > EIP: __lock_acquire.isra.0+0x2e8/0x4e0 > > Code: e8 bd a1 2f 00 85 c0 74 11 8b 1d 08 8f 26 c5 85 db 0f 84 05 1a 00 00 8d 76 00 31 db 8d 65 f4 89 d8 5b 5e 5f 5d c3 8d 74 26 00 <8b> 44 90 04 85 c0 0f 85 4c fd ff ff e9 33 fd ff ff 8d b4 26 00 00 > > EAX: 00000010 EBX: 00000010 ECX: 00000001 EDX: 00000000 > > ESI: f1070040 EDI: f1070040 EBP: f1073e04 ESP: f1073de0 > > DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010097 > > CR0: 80050033 CR2: 00000014 CR3: 05348000 CR4: 001406b0 > > Call Trace: > > lock_acquire+0x42/0x60 > > ? __walk_page_range+0x4d9/0x590 > > _raw_spin_lock+0x22/0x40 > > ? __walk_page_range+0x4d9/0x590 > > __walk_page_range+0x4d9/0x590 > Thanks for looking into this. I've been able to reproduce it locally with that config and I can see what's going wrong here. walk_pte_range() is being called with end=0xffffffff, but the comparison in the function is: if (addr == end) break; So addr never actually equals end, it skips from 0xfffff000 to 0x0. This means the function continues walking straight off the end and dereferencing 'random' ptes. As a quick hack I modified the condition to: if (addr == end || !addr) break; and I can then boot the VM. Clearly that's not the correct solution - I'll go away and have a think about the cleanest way of handling this case and also do some more testing before I resubmit for 5.6. Sorry for the trouble and thanks again for investigating. Steve