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 14FF2D60CEC for ; Mon, 18 Nov 2024 22:09:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 91C286B008C; Mon, 18 Nov 2024 17:09:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A58C6B0092; Mon, 18 Nov 2024 17:09:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 76D536B0093; Mon, 18 Nov 2024 17:09:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 53A066B008C for ; Mon, 18 Nov 2024 17:09:22 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id EF840C02C7 for ; Mon, 18 Nov 2024 22:09:21 +0000 (UTC) X-FDA: 82800605202.13.7596E6B Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf01.hostedemail.com (Postfix) with ESMTP id B9C644000B for ; Mon, 18 Nov 2024 22:08:41 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=mZsF9zc+; spf=pass (imf01.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=pass (policy=none) header.from=soleen.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731967517; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=I8MIscQQe9cVfzpDABcS2/+GpjCcV2Zx/6rrV6Zgl5M=; b=M5HkEJoDD9sysohqReY7jwVFUKIXfBPeRuZIpnAO9iypTcfr24m+dOiT85RlTHFZ2RNEd8 xdbteazpYjVJCI2xUE1UHwrRrh7gN2CGJVD4kIiMPskgsBYNNQYpf92I7YbWlBpjQmemCJ 9rFrnh7svFE1POnUwsgf4x9393g59f0= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=mZsF9zc+; spf=pass (imf01.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=pass (policy=none) header.from=soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731967517; a=rsa-sha256; cv=none; b=cMkhEydW0isSiI180f9VYNC7zPk15uKg+spZDQLzX8bQs3c1LMxryJfXzmVVEvoLPwxdBg 7c6aW+hIlsRhx/rHaEkaAwCMYgjT7eVQM90Ef3mW/neyzd0tykPHOpAzO98jRxm82v5b7z itzuj3enRkJH993n/bgxO7Bi1l2rBZo= Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-4609d8874b1so29095321cf.3 for ; Mon, 18 Nov 2024 14:09:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1731967759; x=1732572559; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=I8MIscQQe9cVfzpDABcS2/+GpjCcV2Zx/6rrV6Zgl5M=; b=mZsF9zc+iL1LKLZGpHO5wpqe/NXbdbYCPPx3I1JkVcx7a4TK6K+kdTZ1CkV+8TgTi1 luS+Q2Z0XQgLeS9li4wXTXd5Tx0YGVMBQdBau++ShrKfei+LCUwdugXp0K6gnFaDApl0 Qxp/lWMKsHBlOsLAdBV5Wl06bk5dmE76oRuq4X1yWyAfVcY7XEBvpNH4DHroxGMoAXCU CoZIUD0eSx4dDQjyevrU8+0GWtloCGYLKew+nI+TMaXppO1ZnKNupcSchXoCuwfm/Vfc 2dvjN9vDlDqLu4wQzzOvkBidX+F4jaKHY6exa5sDFS379EDk5uxZXYuzBLQfVXxtAeXZ 3R5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731967759; x=1732572559; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=I8MIscQQe9cVfzpDABcS2/+GpjCcV2Zx/6rrV6Zgl5M=; b=nGpnvpOiKKeyU44BvPBuY+zVAA1CfY2Js/tPUrWi5jQSqFAF9dHKVLF5w/4ZxIy4I+ Ys91itsEUU5N7MEfUaIIm4xLxxUSFd5H2m/9QRvhNafStaqlp0LBTwvtX0Z4Jhri4vg+ 1O2VnwEHPm9C4/oJFBBoUsT1e95c+UViPQ37r5h8+U7SEbVdWGdK4HkISrk1SBAEKMK4 9id6HYkSiaQafo02x5QZFadRwufFiXcbM1Vw0Iqme6x8TKvJi01YvSDAJvEwJz2SDThT OAapzZhebEAFNxleoxVWEhXHFmAtgw4IbMy+i5qjNq6l7abyy4gJ/jz32BBK1mjVaB9c cT+A== X-Forwarded-Encrypted: i=1; AJvYcCUU9Cte7JrfDN5bLR/kME7X+haHoTNsT9v2ACrnSXPp9r3smtoFfCMVoeFWQ8IMcOtbNHVw82cFMg==@kvack.org X-Gm-Message-State: AOJu0Yw9I/wSCKnksqLtchqQLdyCE0u5YXsEpttoeLZ288IlVa/hOaxI t10cq+L3FQe58dHKT8u8duYHLIKMRc98tgkCCp7uU0phMdzHHaX+qgKSts9dvX08yXnbsrTZFsI 91Dy4R8VCxnspqn/peMSORoMeW+FYYAuAsuxIzQ== X-Google-Smtp-Source: AGHT+IGuHkyDbKbXTopolKHlpXUuh5hPb8odsFN1/bRhiOBmnf88AGPczox19phVHKQRb/h9sm7V4erFguZn2MVlnKk= X-Received: by 2002:ac8:5946:0:b0:458:2764:37d5 with SMTP id d75a77b69052e-46363de80famr188224651cf.6.1731967759219; Mon, 18 Nov 2024 14:09:19 -0800 (PST) MIME-Version: 1.0 References: <20241116175922.3265872-1-pasha.tatashin@soleen.com> In-Reply-To: From: Pasha Tatashin Date: Mon, 18 Nov 2024 17:08:42 -0500 Message-ID: Subject: Re: [RFCv1 0/6] Page Detective To: Roman Gushchin 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, 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@netflix.com, rientjes@google.com, gthelen@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: B9C644000B X-Stat-Signature: fjoqkg8trg9rq7r84sbjj58zkw7gjhyx X-Rspam-User: X-HE-Tag: 1731967721-220066 X-HE-Meta: U2FsdGVkX1+MhSldlWhMIalnWJqUpTKftQ5iDmAA65zJTm2Olb10Q5CijvRRpdsACHOiKpz89ZbarHFSMYIdO0dJxk0ZTszB7W1cpd9vnki2c1tMCZ0H2RfRCURzssCjR1B7DlFDCvoG4TwKbLXP56rHHnYYfW5dGCMRFdO4X0jLGa7MOdHFbA3M3o2lt6qQogHWjuEmxjVkyrnRBevL3vUylu8W0yS4ZsySFP7d4Tx4xg46xVnPe9DbXnzwsKRGlJRT7fqqcPtoo7zSsolKg3Xoum6JasFbaMuRl37RvawRHl46ln8C5xo832s9b2+VnR4Lu6HKkbX2rq+9aNm1sRPPqHwxBwijBL53P2wtrUT9cXAPLGe/+6j/6YOTD3ZQ2dnMwtaV4DrtQf7QOUz41t0kUneF+5PSB5D3pJiW9j6MogGTyhgZwy1vuV4MlGXB2xWSRndGDZWLZQIwDzoLv0TEifEkLfreVummT5rY2IjXSZNmF7i4edc8dhfdROaEmp0CPKO4czKtw8S+e7SyeENTF6ulMR7XTdOjoH8H1yq+Jvrp2MreCkb6C/DlhWCWoRsK2WhIvb6Ib5tg+c6mNkXkrrhE6eQbPYXH5s1PHy68F26zxKGv5tBigDsZoudM3VRGIM/s6R/9ZX0WajBgu9pEL5YUG/io4ulGDmUkHkx0sSUvlXF7mGNRDCShyjucfsP6FgYqf9If8WgzXPK0K8Zxi+q9cu4ocZI6Mh8GfsT5q8AqilDUZXPWSNgtHoZalHvLGlquFbPTl2MHkG87/U8t5+0qyZy+YdjkI76hSYhW1vfMfb6O0Jo3K/FzSsQt8TUVeuWfbanjJGyg8dIHGjJA1jf0W2bfG9ApeIMuooRb1Nv39ziRb8KYuGszh2n53bfBL8v6a6FRV5tvnQnPB3qHNRohVeuaQIMLtKIC4srIIfmut+FFgomtmW1cElfr60EfEN4BUANe5z/gq9O uBQ+iQTt a5/N9NcBOjtiCgm+M6lVlkcswKrRLARbAK1LwFFXJTNUs4gHeB1UBTup9uPKBQGHiOJgAKlh0Rp8eLF66ZpM5B0P+dWvFNAKXRcXfkp0jgZZ7fz7uVoxTrt01gJuOxhytPkaPzA2erVSUytTNoEjPNl6v1YPl+MZXU1Ru8u3OGYEDhNUuTzvzdAmVg9ls+LNE4d/M+vSjLnwqCJKXVT+wMTQBTVkJl2P/+asZvWpdmX3iPWluA0btMRMmCtc6nhhINNxH 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: On Mon, Nov 18, 2024 at 2:11=E2=80=AFPM Roman Gushchin wrote: > > On Sat, Nov 16, 2024 at 05:59:16PM +0000, Pasha Tatashin wrote: > > 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 t= o > > 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. > > This looks questionable both from the security and convenience points of = view. > Given the request-response nature of the interface, the output can be > provided using a "normal" seq-based pseudo-file. We opted to use dmesg for output because it's the standard method for capturing kernel information and is commonly included in bug reports. Introducing a new file would require modifying existing data collection scripts used for reporting, so this approach minimizes disruption to existing workflows. > But I have a more generic question: > doesn't it make sense to implement it as a set of drgn scripts instead > of kernel code? This provides more flexibility, is safer (even if it's bu= ggy, > you won't crash the host) and should be at least in theory equally > powerful. Regarding your suggestion, our plan is to perform reverse lookups in all page tables: kernel, user, IOMMU, and KVM. Currently, we only traverse the kernel and user page tables, but we intend to extend this functionality to IOMMU and KVM tables in future updates, I am not sure if drgn can provide this level of details within a reasonable amount of time. This approach will be helpful for debugging memory corruption scenarios. Often, external mechanisms detect corruption but require kernel-level information for root cause analysis. In our experience, invalid mappings persist in page tables for a period after corruption, providing a window to identify other users of the corrupted page via timely reverse lookup. Additionally, using crash/drgn is not feasible for us at this time, it requires keeping external tools on our hosts, also it requires approval and a security review for each script before deployment in our fleet. Thanks, Pasha