Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp12033615rwl; Tue, 3 Jan 2023 08:07:27 -0800 (PST) X-Google-Smtp-Source: AMrXdXuZv1IjwhUy5cn63y3QcvaQjZnq45fbNldDH8QpZf0QOaaG5NpZ3NkVs9NYy5fRArbeDI6q X-Received: by 2002:a05:6402:12d4:b0:46c:fe2d:a588 with SMTP id k20-20020a05640212d400b0046cfe2da588mr39005283edx.18.1672762047557; Tue, 03 Jan 2023 08:07:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672762047; cv=none; d=google.com; s=arc-20160816; b=XOquDV1n2ZLrKEhcf6BxhUXsKF7BaoooCH7+ab0IcxpDHcbIGHZcs5/Y7mUoM+DcOs tAtcpP385xUAMIPLYA4h1wE2d3OCJosiF9KibXZ7XWvlw+9z4ok9YI3MIXHPLyk6EFlq DZ6WmQI47b/CcK07H7hYsNnK76gtmNnT57GuHpg5vOVvFnDKGPxXgyUyZiVZZFJSOz/K DSSw6g+eSL7/7v1BywWN9ynuHv0VcFv+mPsDdD+bXDS97dzvxwHMA/+LYaAja4av13vB 8RLAoIdLl+MeT5+UgFspfgtUw23ANo6gd6LSYUVggdF+vv4DEaAXjwPdXgQ7WSLDQtVB D06Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=tYB2JZE2N0WqTPWcsY2cJZJix0I7cJCxTxV5O4mNf00=; b=Xsy6crHK99IcEU/PYQnj9XW2ii6V4CxA2+pC8GD37cDctloqqUQKTgdjG91lyMxq0Y MMHPPNrUq+BNWD09BFQEAf7jRgrQTXf39OkvHCIMNv93+jFkyzALRVDcPtbVtP3GmRL0 KaZJgYMg7gEYFdXeol/JA2/I1WEZSs0QDWwWLCuVInRGrunMruRkYckwmHCt/B8eGzRu Un5BNMYrCsoCfZGgjPqSW8WjRD0lLCE8IgsyE/c4G+PORZ8+FivhDwVihwBSmAccxh8w JdddbB7pJq/VmLtRoQ17snLEBkU/M+MgwP8ulQeIpotYSgl8hFGyM2hzN5+XJxTkj7B2 mW+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=e5jv2AL9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sd1-20020a1709076e0100b0084ccee74c20si5376257ejc.497.2023.01.03.08.07.11; Tue, 03 Jan 2023 08:07:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=e5jv2AL9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237834AbjACPcC (ORCPT + 60 others); Tue, 3 Jan 2023 10:32:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51280 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237787AbjACPb6 (ORCPT ); Tue, 3 Jan 2023 10:31:58 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 490851055B for ; Tue, 3 Jan 2023 07:31:54 -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=tYB2JZE2N0WqTPWcsY2cJZJix0I7cJCxTxV5O4mNf00=; b=e5jv2AL9yGM5fFtgcVIjLQBfU6 9nI7bN3KEFRKBs7n+Q+yhCiQIpbuSUEiSWczKzLuui2JWaq0xcmVGJ9UfeEj2tZOrL1BCDp8LBVih /iYkhtP0eJJYwY5R1H63IErkwXLJcZejtyrM9PbgSSjiDkMqwBr/fyovTXH0Zbd3ssmeCRgAJ5hBZ TqlR1LsNWUgE0V25W7RDR1KvZIKR9PLTXMT3EM3nyECFk4nL30HO0utjok8Fn0vfVKangD21FRlVp xdTELx4xqcPxigyfX56kBGZ+rS2fR32CZIT/p7FZb4tvtUbgG3h5iiWzxLQzQqPvGBUSs/6mnOQ+9 AINeyHEg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pCjGR-00EDwR-3V; Tue, 03 Jan 2023 15:31:43 +0000 Date: Tue, 3 Jan 2023 15:31:43 +0000 From: Matthew Wilcox To: Vlastimil Babka Cc: kernel test robot , Hyeonggon Yoo <42.hyeyoo@gmail.com>, oe-lkp@lists.linux.dev, lkp@intel.com, Mike Rapoport , Christoph Lameter , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: A better dump_page() Message-ID: References: <202212312021.bc1efe86-oliver.sang@intel.com> <41276905-b8a5-76ae-8a17-a8ec6558e988@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41276905-b8a5-76ae-8a17-a8ec6558e988@suse.cz> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 03, 2023 at 11:42:11AM +0100, Vlastimil Babka wrote: > Separately we should also make the __dump_page() more resilient. Right. It's not ideal when one of our best debugging tools obfuscates the problem we're trying to debug. I've seen probems like this before, and the problem is that somebody calls dump_page() on a page that they don't own a refcount on. That lets the page mutate under us in some fairly awkward ways (as you've seen here, it seems to be part of several different compound allocations at various points during the dump process). One possibility I thought about was taking our own refcount on the page at the start of dump_page(). That would kill off the possibility of ever passing in a const struct page, and it would confuse people. Also, what if somebody passes in a pointer to something that's not a struct page? Then we've (tried to) modify memory that's not a refcount. I think the best we can do is to snapshot the struct page and the folio it appears to belong to at the start of dump_page(). It'll take a little care (for example, folio_pfn() must be passed the original folio, and not the snapshot), but I think it's doable.