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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3DE3BC433F5 for ; Tue, 10 May 2022 02:28:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C904D6B0074; Mon, 9 May 2022 22:28:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C17356B0075; Mon, 9 May 2022 22:28:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB8A76B0078; Mon, 9 May 2022 22:28:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 94FCD6B0074 for ; Mon, 9 May 2022 22:28:16 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 64AA03151E for ; Tue, 10 May 2022 02:28:16 +0000 (UTC) X-FDA: 79448248992.05.7C2DAFB Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf06.hostedemail.com (Postfix) with ESMTP id 6AF24180062 for ; Tue, 10 May 2022 02:28:13 +0000 (UTC) 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=qVEOoGsIlooEpfnjcilZ8EKGRE3sSWxS4g1FKGjMuzQ=; b=sghlFxVgp9mMCsYDnyEhX8rGzt pODjDgmXBMdUHve+PBFiy6rLDIwmRC08E6XgoQc1VWp8FNzeGJyrZNtGAVmRkEyWLM3AhW/GUjKiw PAlqx3UV0l+rmimlsEHElHfBjndfPCLoHgEdjQSq/0ZJ3K+hyOmuRuWRXv0JOfbgCVAKq3hFopcWR uHntW3bn3MuaAZjzMyiE4/igsw9Ak6Ym13OPF9Z+csD2dH2FL2n/otj5ZLFAj7oawg3onTPKjbY3i /8GifdJP/gsGEMfqQXHlh6vozZOEfKVst+IzMfXe6rsO1dBDqlp8AUJyGIPHKPd5DVYx3Tdnlvaoc jDBWdb9Q==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1noFbZ-004177-LN; Tue, 10 May 2022 02:28:05 +0000 Date: Tue, 10 May 2022 03:28:05 +0100 From: Matthew Wilcox To: Naoya Horiguchi Cc: linux-mm@kvack.org, Miaohe Lin , Christoph Hellwig , Andrew Morton , John Hubbard , Jason Gunthorpe , William Kucharski , Naoya Horiguchi , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/hwpoison: use pr_err() instead of dump_page() in get_any_page() Message-ID: References: <20220427053220.719866-1-naoya.horiguchi@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220427053220.719866-1-naoya.horiguchi@linux.dev> X-Stat-Signature: 11incm3otgbqpk3meth8c76an6f3sxbs Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=sghlFxVg; spf=none (imf06.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 6AF24180062 X-HE-Tag: 1652149693-513548 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 Wed, Apr 27, 2022 at 02:32:20PM +0900, Naoya Horiguchi wrote: > From: Naoya Horiguchi > > The following VM_BUG_ON_FOLIO() is triggered when memory error event > happens on the (thp/folio) pages which are about to be freed: So the real problem is that we're calling dump_page() when we don't have a reference to the page, right? Otherwise it wouldn't be freed. > out: > if (ret == -EIO) > - dump_page(p, "hwpoison: unhandlable page"); > + pr_err("Memory failure: %#lx: unhandlable page.\n", page_to_pfn(p)); It would be nice to get some more information out of the page than that ,.. but taking a refcount inside dump_page() conflicts with the other "would be nice", which is for dump_page() to take a const struct page * so we can (eg) make folio_test_uptodate() take a const struct folio *. We've had some other problems with inconsistent pages being printed in dump_page(). It can be quite confusing when debugging. I still don't have a good solution to that either. I do have a proposal for reforming mapcount which will solve this particular problem, but I'm not quite sure when I'll get to it. This patch is probably the best thing to do for now.