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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 A2C0BC64E8A for ; Wed, 2 Dec 2020 03:43:24 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C8BEB20DD4 for ; Wed, 2 Dec 2020 03:43:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C8BEB20DD4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 58123100EBBBE; Tue, 1 Dec 2020 19:43:23 -0800 (PST) Received-SPF: None (mailfrom) identity=mailfrom; client-ip=2001:8b0:10b:1236::1; helo=casper.infradead.org; envelope-from=willy@infradead.org; receiver= Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3C947100EBBBB for ; Tue, 1 Dec 2020 19:43:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=aT5KzyuPDKMSMYtpVyIWQldGFFFBfyXRI8bueOHPf48=; b=NBvGc24lR65L3NgxDT6K9RJAas rhl9/7C1rv3++q2GuGtZMZU6uNUXc7Im/IPsmPh/7SIS4Xor6I1WuzoPIi7NRnsuXxKDv3RiWnTnZ tGGv39U0IgZ4HZIWflu5qJbi7dwnc20FLeh3qlBmyZJnOLPwY6HFHoyBppBpABInBYF6K0la5o6KJ Z3rLnE6EnhafyABx1fpCelF0YEzc8lOX9zgEQjm8yc8lTNtGOrw2e1dVb/61g4TKgxn6spVVFpq+B p1nBUCxMXdUjj5sJ6AI4FeWwvYkWJ4qFPxNG1gNdTHcftPUJHLZmTLUiMk7ueIs9AS1l2to4yffTW SW93Vrsg==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kkJ2q-0007t4-M0; Wed, 02 Dec 2020 03:43:08 +0000 Date: Wed, 2 Dec 2020 03:43:08 +0000 From: Matthew Wilcox To: Dan Williams Subject: Re: mapcount corruption regression Message-ID: <20201202034308.GD11935@casper.infradead.org> References: <20201201022412.GG4327@casper.infradead.org> <20201201204900.GC11935@casper.infradead.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Message-ID-Hash: 5D62BERX72TZ5OM5QRXPP4CBJQPY7GFV X-Message-ID-Hash: 5D62BERX72TZ5OM5QRXPP4CBJQPY7GFV X-MailFrom: willy@infradead.org X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation CC: "Shutemov, Kirill" , Linux Kernel Mailing List , Linux MM , linux-nvdimm , Vlastimil Babka , Yi Zhang X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, Dec 01, 2020 at 06:28:45PM -0800, Dan Williams wrote: > On Tue, Dec 1, 2020 at 12:49 PM Matthew Wilcox wrote: > > > > On Tue, Dec 01, 2020 at 12:42:39PM -0800, Dan Williams wrote: > > > On Mon, Nov 30, 2020 at 6:24 PM Matthew Wilcox wrote: > > > > > > > > On Mon, Nov 30, 2020 at 05:20:25PM -0800, Dan Williams wrote: > > > > > Kirill, Willy, compound page experts, > > > > > > > > > > I am seeking some debug ideas about the following splat: > > > > > > > > > > BUG: Bad page state in process lt-pmem-ns pfn:121a12 > > > > > page:0000000051ef73f7 refcount:0 mapcount:-1024 > > > > > mapping:0000000000000000 index:0x0 pfn:0x121a12 > > > > > > > > Mapcount of -1024 is the signature of: > > > > > > > > #define PG_guard 0x00000400 > > > > > > Oh, thanks for that. I overlooked how mapcount is overloaded. Although > > > in v5.10-rc4 that value is: > > > > > > #define PG_table 0x00000400 > > > > Ah, I was looking at -next, where Roman renumbered it. > > > > I know UML had a problem where it was not clearing PG_table, but you > > seem to be running on bare metal. SuperH did too, but again, you're > > not using SuperH. > > > > > > > > > > (the bits are inverted, so this turns into 0xfffffbff which is reported > > > > as -1024) > > > > > > > > I assume you have debug_pagealloc enabled? > > > > > > Added it, but no extra spew. I'll dig a bit more on how PG_table is > > > not being cleared in this case. > > > > I only asked about debug_pagealloc because that sets PG_guard. Since > > the problem is actually PG_table, it's not relevant. > > As a shot in the dark I reverted: > > b2b29d6d0119 mm: account PMD tables like PTE tables > > ...and the test passed. That's not really surprising ... you're still freeing PMD tables without calling the destructor, which means that you're leaking ptlocks on configs that can't embed the ptlock in the struct page. I suppose it shows that you're leaking a PMD table rather than a PTE table, so that might help track it down. Checking for PG_table in free_unref_page() and calling show_stack() will probably help more. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org