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=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 C2EBBC43331 for ; Wed, 1 Apr 2020 14:05:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7FCE6206F8 for ; Wed, 1 Apr 2020 14:05:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=shutemov-name.20150623.gappssmtp.com header.i=@shutemov-name.20150623.gappssmtp.com header.b="jfklC9tX" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7FCE6206F8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1AB778E0006; Wed, 1 Apr 2020 10:05:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 15D058E0001; Wed, 1 Apr 2020 10:05:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 073408E0006; Wed, 1 Apr 2020 10:05:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0131.hostedemail.com [216.40.44.131]) by kanga.kvack.org (Postfix) with ESMTP id E41C88E0001 for ; Wed, 1 Apr 2020 10:05:48 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 972CF82499A8 for ; Wed, 1 Apr 2020 14:05:48 +0000 (UTC) X-FDA: 76659459576.11.lip05_89f9d10de4c4b X-HE-Tag: lip05_89f9d10de4c4b X-Filterd-Recvd-Size: 7284 Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Wed, 1 Apr 2020 14:05:48 +0000 (UTC) Received: by mail-lj1-f193.google.com with SMTP id p10so25649843ljn.1 for ; Wed, 01 Apr 2020 07:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=DX54l6mXZgvg8fNpjxDfkSkS7a7YXpNmjQ66Zp5QZwk=; b=jfklC9tXAS2ZFL+y9Q7gH4nZZ7YnfJHqPBdCK1oMtQTsFEAaEdcWhbSxHq9hmP0Lpl GV5N6ZofZpSSv9pg0jxtoYArNo3d+4ZDGUkXSkHuknLnSDOLQJAMHN4buq4HzDbUveED aZyH4HmDjF5plF7q6ujTQzRgMt09SwHAaf6M8AKL+wRcKqVe+5xUyGX6JqVmZvKipbin XHrLDj2GHRRndj9fm8ptwKmyWNOK6CwozSav+H4ChEFTRMSZVbB94fJl/L1FwUdPl6ET OeBcV6N2BcItxUDf8iv0TFHg1EUHt96T1/QMrcx6Ub89/ECxQ3O7CE/FxQxEQFVJmmqw /4sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=DX54l6mXZgvg8fNpjxDfkSkS7a7YXpNmjQ66Zp5QZwk=; b=TSLwyynYtDMMHUGQbBghMlTGqmt+Z5rAeQAVRK796DpHtLJbqvU+9SxbA6MtZbWh4P 099aXv7F8MibF5JcrwSYxU4qZLBkk7nOtPLYIxKE1HXUA5ila1Yfskj6k/b6VsNnOAvA KY7T3fOapv6rmYaFFU370iQLprhn/gVLxkaoayo/UeYQf6fkY++ySIJOtD20dJC1hdxZ BhUkMZXOaIVftvoC+ZJOIMskaCX/+723Drr5F/klqJjNnLu0sQnTU0p67XYicFex0oJV TMmr1KWC4HpBovXS4rVtwO7LWzjMwk6U3ksvjQ9S+CS54MbI7mXylQZOW5k/LJGIwuKs VWoA== X-Gm-Message-State: AGi0PuZvD3kWLIajNuwMml4FhvI2qGJaCBAe92gpsZlZLCOyOUkXXc6X Lkq1fMntQSVGMDjiZeQbSHiIcg== X-Google-Smtp-Source: APiQypKHorHX7t1AMghmwqPTG5hZghSH9yGsQdrU3naHV7seLQRyJU/BjPlzWXNzLdpcl6oyqKkOgA== X-Received: by 2002:a05:651c:1102:: with SMTP id d2mr13519723ljo.102.1585749946356; Wed, 01 Apr 2020 07:05:46 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id e1sm1297999ljo.16.2020.04.01.07.05.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Apr 2020 07:05:45 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id 24CDE1020AE; Wed, 1 Apr 2020 17:05:44 +0300 (+03) Date: Wed, 1 Apr 2020 17:05:44 +0300 From: "Kirill A. Shutemov" To: Vlastimil Babka Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Matthew Wilcox , John Hubbard , "Kirill A. Shutemov" , Petr Tesarik Subject: Re: [PATCH] mm, dump_page(): do not crash with invalid mapping pointer Message-ID: <20200401140544.pkhgfmo5pks3dw6v@box> References: <20200331165454.12263-1-vbabka@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200331165454.12263-1-vbabka@suse.cz> 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 Tue, Mar 31, 2020 at 06:54:54PM +0200, Vlastimil Babka wrote: > We have seen a following problem on a RPi4 with 1G RAM: > > BUG: Bad page state in process systemd-hwdb pfn:35601 > page:ffff7e0000d58040 refcount:15 mapcount:131221 mapping:efd8fe765bc80080 index:0x1 compound_mapcount: -32767 > Unable to handle kernel paging request at virtual address efd8fe765bc80080 > Mem abort info: > ESR = 0x96000004 > Exception class = DABT (current EL), IL = 32 bits > SET = 0, FnV = 0 > EA = 0, S1PTW = 0 > Data abort info: > ISV = 0, ISS = 0x00000004 > CM = 0, WnR = 0 > [efd8fe765bc80080] address between user and kernel address ranges > Internal error: Oops: 96000004 [#1] SMP > Modules linked in: btrfs libcrc32c xor xor_neon zlib_deflate raid6_pq mmc_block xhci_pci xhci_hcd usbcore sdhci_iproc sdhci_pltfm sdhci mmc_core clk_raspberrypi gpio_raspberrypi_exp pcie_brcmstb bcm2835_dma gpio_regulator phy_generic fixed sg scsi_mod efivarfs > Supported: No, Unreleased kernel > CPU: 3 PID: 408 Comm: systemd-hwdb Not tainted 5.3.18-8-default #1 SLE15-SP2 (unreleased) > Hardware name: raspberrypi rpi/rpi, BIOS 2020.01 02/21/2020 > pstate: 40000085 (nZcv daIf -PAN -UAO) > pc : __dump_page+0x268/0x368 > lr : __dump_page+0xc4/0x368 > sp : ffff000012563860 > x29: ffff000012563860 x28: ffff80003ddc4300 > x27: 0000000000000010 x26: 000000000000003f > x25: ffff7e0000d58040 x24: 000000000000000f > x23: efd8fe765bc80080 x22: 0000000000020095 > x21: efd8fe765bc80080 x20: ffff000010ede8b0 > x19: ffff7e0000d58040 x18: ffffffffffffffff > x17: 0000000000000001 x16: 0000000000000007 > x15: ffff000011689708 x14: 3030386362353637 > x13: 6566386466653a67 x12: 6e697070616d2031 > x11: 32323133313a746e x10: 756f6370616d2035 > x9 : ffff00001168a840 x8 : ffff00001077a670 > x7 : 000000000000013d x6 : ffff0000118a43b5 > x5 : 0000000000000001 x4 : ffff80003dd9e2c8 > x3 : ffff80003dd9e2c8 x2 : 911c8d7c2f483500 > x1 : dead000000000100 x0 : efd8fe765bc80080 > Call trace: > __dump_page+0x268/0x368 > bad_page+0xd4/0x168 > check_new_page_bad+0x80/0xb8 > rmqueue_bulk.constprop.26+0x4d8/0x788 > get_page_from_freelist+0x4d4/0x1228 > __alloc_pages_nodemask+0x134/0xe48 > alloc_pages_vma+0x198/0x1c0 > do_anonymous_page+0x1a4/0x4d8 > __handle_mm_fault+0x4e8/0x560 > handle_mm_fault+0x104/0x1e0 > do_page_fault+0x1e8/0x4c0 > do_translation_fault+0xb0/0xc0 > do_mem_abort+0x50/0xb0 > el0_da+0x24/0x28 > Code: f9401025 8b8018a0 9a851005 17ffffca (f94002a0) > ---[ end trace 703ac54becfd8094 ]--- > > Besides the underlying issue with page->mapping containing a bogus value for > some reason, we can see that __dump_page() crashed by trying to read the > pointer at mapping->host, turning a recoverable warning into full Oops. > > It can be expected that when page is reported as bad state for some reason, the > pointers there should not be trusted blindly. So this patch treats all data in > __dump_page() that depends on page->mapping as lava, using > probe_kernel_read_strict(). Ideally this would include the dentry->d_parent > recursively, but that would mean changing printk handler for %pd. Chances of > reaching the dentry printing part with an initially bogus mapping pointer > should be rather low, though. > > Also prefix printing mapping->a_ops with a description of what is being > printed. In case the value is bogus, %ps will print raw value instead of > the symbol name and then it's not obvious at all that it's printing a_ops. > > Reported-by: Petr Tesarik > Signed-off-by: Vlastimil Babka > --- > mm/debug.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++------ > 1 file changed, 50 insertions(+), 6 deletions(-) I'm not sure it worth the effort. It looks way too complex for what it does. I also expect it to slowdown dump_page(), which is hotpath for some debug scenarios :P Maybe just move printing this info to the end, so we would see the rest even if ->mapping is bogus? -- Kirill A. Shutemov