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 7602FD711B4 for ; Wed, 20 Nov 2024 15:29:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 061546B0083; Wed, 20 Nov 2024 10:29:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F2C8D6B0085; Wed, 20 Nov 2024 10:29:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DCD926B008A; Wed, 20 Nov 2024 10:29:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id BC8EA6B0083 for ; Wed, 20 Nov 2024 10:29:40 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6BB73120D8E for ; Wed, 20 Nov 2024 15:29:40 +0000 (UTC) X-FDA: 82806856608.22.8B48EF4 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by imf26.hostedemail.com (Postfix) with ESMTP id ADEC2140016 for ; Wed, 20 Nov 2024 15:28:58 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=HdtOOlFJ; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf26.hostedemail.com: domain of ak@linux.intel.com has no SPF policy when checking 198.175.65.15) smtp.mailfrom=ak@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732116486; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GMJRSIN/jwN1mEeXDPhC5UQ+MYY/wdAISwzlBog0b14=; b=vOXtoJQNTw2YvGDW0uE++58IN66c2yrHuGh+ppLGMjsUR/kD3LK90p0LxoVmoRnQezgUXu 1RVZoHCXwR1U7tbMhAXhvLjJnidh06ukX3w9PSENsmVGW/hKoLbbl0aQtSykSDjAG6Bvfe uEzlvWLud11pxX8/s4HuhTpAifrryK4= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=HdtOOlFJ; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf26.hostedemail.com: domain of ak@linux.intel.com has no SPF policy when checking 198.175.65.15) smtp.mailfrom=ak@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732116486; a=rsa-sha256; cv=none; b=Dgq/6iJRMJlZ850yj7Dlnwp07oCzZi4dQWPSl4SrrMV6nj1jSRIfYZX+mMf9IhpPQNLXcR sTInvpV8HryxW2Qf3101SEQUPKnxndqQZgXiwhozq5kbBDWvhVgA6tHf8UhhFFAxj3aJTk 0Ld3T98EXQ8WhY8qsjJ+m+XulxsdhGg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1732116578; x=1763652578; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=GMJRSIN/jwN1mEeXDPhC5UQ+MYY/wdAISwzlBog0b14=; b=HdtOOlFJ74JEKAF4nHTy4c9TAPSFqb3T/90/eFHKYfzH6bSGV/vJl55R 5KzDzqm+/rA6lwzH7doos5ibDuFBnxgVKHrvC9zAvV0mAH/hSFY79jE44 KJzw+Cvr/Y/r0qd5Nu0XzX1Isqh97z4tBTciRODkqDiEmtNFlr84vQlfu g+vj9HS52mC00YgPafNVgrBzvjTFteSrneU+OAg5G/sSCzN0jw9++WARo c8C9fTSOdNlFMcEEgrWaKTOeP+Qp9HAJphkGYbnNPyJOkxpxFzWbwziYN el8uLGW7EjrETPTvu7IEmZSJXcarSPfIsaO6kp0ofaJIDui+d3Yp38pav g==; X-CSE-ConnectionGUID: +zRYfAVcSKu+wD7Z20yNPQ== X-CSE-MsgGUID: lsuIndZ9TbK1fOTRs4VY3g== X-IronPort-AV: E=McAfee;i="6700,10204,11262"; a="35856473" X-IronPort-AV: E=Sophos;i="6.12,170,1728975600"; d="scan'208";a="35856473" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Nov 2024 07:29:36 -0800 X-CSE-ConnectionGUID: JioBrdkvQk2Y5jNMYdMdmw== X-CSE-MsgGUID: ev1M0HImQeKcY4srIRu0nQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,170,1728975600"; d="scan'208";a="89533919" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.54.38.190]) by fmviesa006.fm.intel.com with ESMTP; 20 Nov 2024 07:29:35 -0800 Received: by tassilo.localdomain (Postfix, from userid 1000) id C65E8301B9F; Wed, 20 Nov 2024 07:29:34 -0800 (PST) From: Andi Kleen To: Pasha Tatashin Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, cgroups@vger.kernel.org, linux-kselftest@vger.kernel.org, akpm@linux-foundation.org, corbet@lwn.net, derek.kiernan@amd.com, dragan.cvetic@amd.com, arnd@arndb.de, gregkh@linuxfoundation.org, viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, tj@kernel.org, hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, Liam.Howlett@oracle.com, lorenzo.stoakes@oracle.com, vbabka@suse.cz, jannh@google.com, shuah@kernel.org, vegard.nossum@oracle.com, vattunuru@marvell.com, schalla@marvell.com, david@redhat.com, willy@infradead.org, osalvador@suse.de, usama.anjum@collabora.com, andrii@kernel.org, ryan.roberts@arm.com, peterx@redhat.com, oleg@redhat.com, tandersen@ Subject: Re: [RFCv1 0/6] Page Detective In-Reply-To: <20241116175922.3265872-1-pasha.tatashin@soleen.com> (Pasha Tatashin's message of "Sat, 16 Nov 2024 17:59:16 +0000") References: <20241116175922.3265872-1-pasha.tatashin@soleen.com> Date: Wed, 20 Nov 2024 07:29:34 -0800 Message-ID: <87wmgxvs81.fsf@linux.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: ADEC2140016 X-Stat-Signature: xxiudqhdzpic4rfoxhrje57dgu9ouosu X-HE-Tag: 1732116538-832808 X-HE-Meta: U2FsdGVkX18vTuzZqkVq1NA111Vn1ltZEjMGvnl4l16hgTM76bWzkFYVMeSst5pQRdtm3k9TKkU//fniEGNt2cwE0OcjgizfiKrK3ohwW8FlopgpvWbA28YovY8QJb9RNUDuKTZNE06u+kQZZpuv3120KRJZvVC0wJIsOGBM5ljlqCg6a3HqeyOXf/WwE6ulyoi9NHpVxQwBNGBA8rapuGoaWJ9Y3YXpnTC8p1JYOCvpktvIHJBad1iwXmW9YPXmpu58GNjORWw41pWyTuo2mG8/v1bkZhSj3O/heAKgBVjpBbaWUBEdeCvKPZgIWsO+ubWGYV2Fk3LTmln4gaHa2S5ZAsDmenm/cqSvqhsjj/dm9/wQufYhR02Hzc/AoEUiQEb/z/YPyDeIa2K3gGlD6a/xJE6+SsV/AKsB7FMJvSgxgkpuugSUjG7cZJl3ziAUkhmO2oT6hGtDg0qPg4EZfkqUepqavWCEstTMXn/AIC+xA2uKWsuuimbc+XDWqhD4LprYsOdEGeFZRBktazS8M7gxuJBMmMz/JRhgextae7eQCLoctNtdY0j+d/5d9kGeG0eDUHkUw3c3Biq2so1w7xKD/CHYSopvr6ydckchp3ii17akKdzzfYLGDgcFWrbVlMbnumOX7RcukippJnq0HW9Fl59v7/D7q77cEs0zSwVLr2VuNcqfk2BCmZNfiYGxbPGEHtDsbQz+P69Kz3jkfyWGtyMehR2WnETcdsVWc8IJ8RFPsVA4q3FlHNxOwE550r17+SqTMUoPYAtOYgj6id7ynVLBLSTa4M/lHsSjDuu2BtMfSEJu9g0kwH6hTSr278PjSTTslyvuDXri/LB9zfAzPGyVf4aW2fEQi8WAPDjr3z4gCBzxdEjhng50x0mj9kuxDQh78/QL/9TyiuohEFKf2U5a1uUGzK+Zd8bPSmsCJndZ4IYhI/4UQVX6qnTZlDJJTDiDSQVd/uaBhXI N1yrCAHj toRAFIvqCdJZwyVKB+4cLVUaiXy3E55WitWU0KnTaT2Hc14A4EEOtjHHPdrdwAYFQ5XQsXuaFS/M8VLCy6Iu5h2FeYBAtSO0HmRD92XpN414w6pSNuveBrtTqDsM2mKYgGhH3Mo/eRGg1flo2iFElT8/SSNa90KuhVSgg 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: List-Subscribe: List-Unsubscribe: Pasha Tatashin writes: > Page Detective is a new kernel debugging tool that provides detailed > information about the usage and mapping of physical memory pages. > > It is often known that a particular page is corrupted, but it is hard to > extract more information about such a page from live system. Examples > are: > > - Checksum failure during live migration > - Filesystem journal failure > - dump_page warnings on the console log > - Unexcpected segfaults > > Page Detective helps to extract more information from the kernel, so it > can be used by developers to root cause the associated problem. > > It operates through the Linux debugfs interface, with two files: "virt" > and "phys". > > The "virt" file takes a virtual address and PID and outputs information > about the corresponding page. > > The "phys" file takes a physical address and outputs information about > that page. > > The output is presented via kernel log messages (can be accessed with > dmesg), and includes information such as the page's reference count, > mapping, flags, and memory cgroup. It also shows whether the page is > mapped in the kernel page table, and if so, how many times. A lot of all that is already covered in /proc/kpage{flags,cgroup,count) Also we already have /proc/pid/pagemap to resolve virtual addresses. At a minimum you need to discuss why these existing mechanisms are not suitable for you and how your new one is better. If something particular is missing perhaps the existing mechanisms can be extended? Outputting in the dmesg seems rather clumpsy for a production mechanism. I personally would just use live crash or live gdb on /proc/kcore to get extra information, although I can see that might have races. -Andi