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 E19EAD44177 for ; Tue, 19 Nov 2024 15:53:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 673816B007B; Tue, 19 Nov 2024 10:53:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FBE16B009C; Tue, 19 Nov 2024 10:53:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 475776B00A1; Tue, 19 Nov 2024 10:53:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 263CE6B007B for ; Tue, 19 Nov 2024 10:53:51 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CF5888064B for ; Tue, 19 Nov 2024 15:53:50 +0000 (UTC) X-FDA: 82803286692.17.0F65527 Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by imf28.hostedemail.com (Postfix) with ESMTP id 3ED8DC0018 for ; Tue, 19 Nov 2024 15:52:55 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qLNS4AuT; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf28.hostedemail.com: domain of jannh@google.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732031538; 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=oZBz6My2fl2cEQ/H4m7spItLuifNL3YkZ0yddOy41YQ=; b=NnAdu8xetxLVgO+mEUQ3b6S/EuRhQjyMmZ1yZJQT/8t2CVSVWIiQ2/e0naBoeObJtOhg08 kEsQk3Pi4PI1HesFwJmzNXdT9KBG30Y5Wb3CQG0onQr2ESoAMwJrOs6+hPkKuOU/6ityT0 iZymkFHcgOuZsYrK9h/mSBYslJcetLk= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qLNS4AuT; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf28.hostedemail.com: domain of jannh@google.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732031538; a=rsa-sha256; cv=none; b=AqMdnFUuIWUzWXw1ADS03dvlIbDd5YL3Flgpn87PFXmOUnnOdPy76FkfqiZP80yBcGe4TD ERnud9MsAXDQ85MO+UQQFHijcRLgmTHnOLmSCZU6vrl1fL625UrN0ezoTchD3wZiR4oLVQ JRfVRFECZub02L9+N+M3DezzjFTIfP0= Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-5cfc264b8b6so11896a12.0 for ; Tue, 19 Nov 2024 07:53:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1732031627; x=1732636427; 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=oZBz6My2fl2cEQ/H4m7spItLuifNL3YkZ0yddOy41YQ=; b=qLNS4AuTe6Bkza/GOscYWmtPdTdi2Ea/SRc3Tx6dHWiit9IpEMXrocvTWrbEjrjwJR IcP45nJi6gcPQc05pZQfitZVlmq2oJOEZhuCnycR4Qal2AgxX1hF8zOfKBNxzsQUDB5S GylhBoEzzQZ01wswYOYDsKiZizlU+TDIdMbUXbUUYH4m24S+FhumiUNTHPJnXLdtq17R E3AyiDJna+oEbCRDp4ZuRDirTYS55KyvBzAMofYM8PCm9IlX+tLxVhQl+GqFJHjYu7zt 3RKQAqIa6a2vgqkh0wbgoIf97JskNfU64qecX8ouRlKgEPgoezi2eY+YxCJw59f2CMUa frxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732031627; x=1732636427; 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=oZBz6My2fl2cEQ/H4m7spItLuifNL3YkZ0yddOy41YQ=; b=lolRDkN7Hg5OxZZvl0k6av6LBm+KxG+IDdG9o8c7BATvzcIv5YKk3AjNDR8ukHpv9u gbY7iZtvQ3Wj62n2/iDhlD7m0ruJlwBEgMyPQfAypN9Op7ch640YYA9hKfSpXRoHPU41 ZOiCooCyaOlFTbYVNSYaIsHFkuUeFSu8Fz+kjTtY3zPzOrnRrPKZBXLC06Xl8CoTasYY AVSK/DK1U+aeJDn2VALpt3js0QYWg43hETTb8dDru1GX98ZSMjwI0z04DLUEcI36/XYY 5mYTSRj7QN1dqPbwUfUyFCRDTTb/A4JESOzzSiYS5lWD9nZOgEleiXCBMu1tX3X9EsAk ufSA== X-Forwarded-Encrypted: i=1; AJvYcCVz4sP0sIXx2+N+B7OgJBtZMe8yqVDnnzwS3V/w+w5TfxoxCYKj2dJOqZlEbhrROebMygSs0mHp8Q==@kvack.org X-Gm-Message-State: AOJu0Yxp3Y8PU1B/j9OPAelmGdiPYQ/jP2leyT5VwjsHGOlgCrbLQ8ki rvIJfgaitunotsgvaWfEQpjlQAwNl/E6JjcqQipUSN9AvETTcxu55wJ+OnxQnWMtQze0ZAdJyBg lyX2wnxExtXajwj8jbD/fKOQewThvcbTqnxAh X-Gm-Gg: ASbGncuUtA+dS7a5huqgMeaweK4dOQRX8j0Brbqek8XeqsbO2WPlua4AineCyg4QmzD rQgoWNakdsHmoMHm3Fj/flfMwT/+Qz957wXLjyjefjhFSLUOTOtHx1l7aL4s= X-Google-Smtp-Source: AGHT+IGNsuMEPDGgLQcJBGgUTcQNAXs25llr0/NFfx7zpUAdIJ2qG87STQ6ogH4Jn3C0zEhl2cmBRbcH53+WD7m9EI4= X-Received: by 2002:aa7:c251:0:b0:5cf:f20c:bdf0 with SMTP id 4fb4d7f45d1cf-5cff20cbec4mr2276a12.4.1732031626961; Tue, 19 Nov 2024 07:53:46 -0800 (PST) MIME-Version: 1.0 References: <20241116175922.3265872-1-pasha.tatashin@soleen.com> In-Reply-To: From: Jann Horn Date: Tue, 19 Nov 2024 16:53:10 +0100 Message-ID: Subject: Re: [RFCv1 0/6] Page Detective To: Pasha Tatashin Cc: Lorenzo Stoakes , 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, vbabka@suse.cz, 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, linux-hardening@vger.kernel.org, Kernel Hardening Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 3ED8DC0018 X-Stat-Signature: w6pdq3bpfkpkprfh5nr54bt5penn4fyk X-HE-Tag: 1732031575-664773 X-HE-Meta: U2FsdGVkX1/VEMT/auUc7vkI2e02haXBlu/BAgBL5LohJ5Y6ELkxtFcwvodkqHC8AFrBePHCyRAvUS1r/8EGQIjhym2vlxLVWsw90T03sLkzSIjK/iX0oaVFlsVu+nQ7ZTgYIPeW5LWZvv2VSTmSlN8JUCFmSwTPqIEbxqm+uWjasIKhjRsxIAp6dPv/ShwOWyzZTliPKhhVnIczz41V7li2tKbamRPUo0/Htx/f7YX/r3A+VL14dDLHpFWEaHAByl0Dn+UamjkmVMq6Xz+XMsLeWLNFjrZ46oYTGYsdpKCmQVciUQ8YGfuy4iorT57vPfTFsx8rzvZvJfJh1D4K/SFX+IxuwyYUyzXvGMPGpYx6TEBejSIPF1MUz7L7TvKBaOd3Iyv0ypYLmhGwHwwTUh5Yxbs3XePiekybYVIZGw0MM1c5tEtc0Hw0y50IOmyt/1tQlmUNaHI8Aur3THLDrnp59IGxhySd8Y9wjzlXf13kZr4AEInde0BJMqUMRamGq33FZUGnibAczCtn1rkkfG1c9CM3h8xoRpp5ZNs0AJ/9Dk8h59s7SOD5QaGBztzISKc5moCT16e5wRpi3odJktc0vVV/tRDEGeYEbJrHPmAkliM6/t1Tgdlq+ZISf4nST6BeTh37/k2cruObpTqV7uC6pFfXOP+R1pk7lQOoYs6LNTsmJkcOMeTkZ0G2wFl+TFUyHBBAnvsTybdlnKwnNpzKjwZ/apypQwgXqA9mLsjLJsYO1QnqTeHJ/I6AG4LSf1QjFLC51OGNpvvzX3BC3KZXr1FN/GcCWV4QY6OHCXcVkfunh9bh68PHzeLG+eIhiq91hOtr102KKJDy/Tspijen/tlBFX+Yvk+vPVfcakfyDz/2PHDVvhXAe3Ba7L86YfV0/kNIA//pBryhvNzHuY2zBHfabY1FxfwRfosP/BHrEMw8UraAG+WcSog/Ozh/giPYWrTe/iXeJTDFSyX FamCQGUM BjQc6Nf7J+FNpscsSQ+aHcT/EZuS6Pxh0PSc8XQZdJD/OW41tUReWW4s9KoD80nrrfiYgiI++rWq/nPgfk9/O4bdHBYBWN9UK3HopsCbzmTmOTG1yOfyNOsvKKJ8BRt6yoqBZMjh8OG2nYcuIkErgfz+Mzb8ZL15p3tqQWCUh7/gee2Uw8vZMNQPM2Cu3p4M5C0TQQXGF4WqbtRscfKDZLN4NQOrsmGpJ6B3GorIcpKu2vF0hXz84vvAiyKInJviCk31EhIzHzdrVLV4X9fXVjeP5iw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000464, 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 Tue, Nov 19, 2024 at 4:14=E2=80=AFPM Pasha Tatashin wrote: > On Tue, Nov 19, 2024 at 7:52=E2=80=AFAM Jann Horn wrot= e: > > On Tue, Nov 19, 2024 at 2:30=E2=80=AFAM Pasha Tatashin > > wrote: > > > > Can you point me to where a refcounted reference to the page comes > > > > from when page_detective_metadata() calls dump_page_lvl()? > > > > > > I am sorry, I remembered incorrectly, we are getting reference right > > > after dump_page_lvl() in page_detective_memcg() -> folio_try_get(); I > > > will move the folio_try_get() to before dump_page_lvl(). > > > > > > > > > So I think dump_page() in its current form is not something we = should > > > > > > expose to a userspace-reachable API. > > > > > > > > > > We use dump_page() all over WARN_ONs in MM code where pages might= not > > > > > be locked, but this is a good point, that while even the existing > > > > > usage might be racy, providing a user-reachable API potentially m= akes > > > > > it worse. I will see if I could add some locking before dump_page= (), > > > > > or make a dump_page variant that does not do dump_mapping(). > > > > > > > > To be clear, I am not that strongly opposed to racily reading data > > > > such that the data may not be internally consistent or such; but th= is > > > > is a case of racy use-after-free reads that might end up dumping > > > > entirely unrelated memory contents into dmesg. I think we should > > > > properly protect against that in an API that userspace can invoke. > > > > Otherwise, if we race, we might end up writing random memory conten= ts > > > > into dmesg; and if we are particularly unlucky, those random memory > > > > contents could be PII or authentication tokens or such. > > > > > > > > I'm not entirely sure what the right approach is here; I guess it > > > > makes sense that when the kernel internally detects corruption, > > > > dump_page doesn't take references on pages it accesses to avoid > > > > corrupting things further. If you are looking at a page based on a > > > > userspace request, I guess you could access the page with the > > > > necessary locking to access its properties under the normal locking > > > > rules? > > > > > > I will take reference, as we already do that for memcg purpose, but > > > have not included dump_page(). > > > > Note that taking a reference on the page does not make all of > > dump_page() fine; in particular, my understanding is that > > folio_mapping() requires that the page is locked in order to return a > > stable pointer, and some of the code in dump_mapping() would probably > > also require some other locks - probably at least on the inode and > > maybe also on the dentry, I think? Otherwise the inode's dentry list > > can probably change concurrently, and the dentry's name pointer can > > change too. > > Agreed, once reference is taken, the page identity cannot change (i.e. > if it is a named page it will stay a named page), but dentry can be > renamed. I will look into what can be done to guarantee consistency in > the next version. There is also a fallback if locking cannot be > reliably resolved (i.e. for performance reasons) where we can make > dump_mapping() optionally disabled from dump_page_lvl() with a new > argument flag. Yeah, I think if you don't need the details that dump_mapping() shows, skipping that for user-requested dumps might be a reasonable option.