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 F0DA2D6C287 for ; Tue, 19 Nov 2024 18:51:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6FC2F6B0083; Tue, 19 Nov 2024 13:51:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6AC2F6B0088; Tue, 19 Nov 2024 13:51:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 573766B0089; Tue, 19 Nov 2024 13:51:34 -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 3C0376B0083 for ; Tue, 19 Nov 2024 13:51:34 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E1E31807B9 for ; Tue, 19 Nov 2024 18:51:33 +0000 (UTC) X-FDA: 82803736638.12.6CFFCF7 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf05.hostedemail.com (Postfix) with ESMTP id 0D6DE100008 for ; Tue, 19 Nov 2024 18:49:54 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=EvgMhu7T; dmarc=none; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732042157; a=rsa-sha256; cv=none; b=HngqrvLz1/IrjaNBl8mR/oJSpTwUv5uOZMw7KbYh1MQUolwbtGX+pNNn0z6m+8PLKDHPNf MXoKFlia72RBfWLZ36bzZL218/Joe+PNXU7Py510VZmCAdAoUL5a6ar2AtUDFWTv93Dp3s iLAB6nbMf8AQ8h2edq01ewaOgO/R03c= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=EvgMhu7T; dmarc=none; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732042157; 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=89rXTlyvwZf7wy1AENCo71hFPFgxU7iIh40Yvq9+ziw=; b=MIaIL9h3EPw43p3gWp9XUWTnrnPDYSTMQ9VrxBQQU0slJjrr4d7ABzj2sklsCEQNJB42FI lObBqNTkkAyW0oArn/52zMAx1NqJPR2nOY6q2kyUZ4IRCuj6VNpomoFajs5q1oeYw7xhkp oM0FuW9N/zPXPuE+CG6jsfzoLmzudXY= 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=89rXTlyvwZf7wy1AENCo71hFPFgxU7iIh40Yvq9+ziw=; b=EvgMhu7TluBgBeWrE8nDe71+fU A9TW71iacELiK7rlvJ+FONkzEyTxhuiOuOojwE55G0XCDYerbTnkDeLl21TLOOs+2Zv5qZrdn+wAK S2LNeIqWba4oXI3yV/0S2u79Hv5T5bi8jccGMw09kFvwWR1domGUK5TDPKA+3wRRWKtn6GqbJlS+f 0vJTptsx3NpYYq/f1skl8VjkAZC5xpCI68xYV1zdM8Wkq9WZ4m59YG4Jh2/Ae88RhgFXOi9f2xEQ1 +iT6gbvy7MPbJUG16lAJlFSsgkL3qzyp/Z0Spi/lcuKDtoAGlwrPDbLeV7s0TcUOdQr85sqRgXOrI YVUCngYQ==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tDTJr-00000004PU4-1HUc; Tue, 19 Nov 2024 18:51:23 +0000 Date: Tue, 19 Nov 2024 18:51:23 +0000 From: Matthew Wilcox To: Jann Horn Cc: Pasha Tatashin , 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, 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 Subject: Re: [RFCv1 0/6] Page Detective Message-ID: References: <20241116175922.3265872-1-pasha.tatashin@soleen.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 0D6DE100008 X-Stat-Signature: jc9fy1oy63fpmx97ut54uqzernncwdhr X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1732042194-475157 X-HE-Meta: U2FsdGVkX180EVjhFAxJJxkXAezldz6bP4kOkx5a+sjiEZgeRC0bGIP9X0BLiX44O0OTRz89+/mFt59YRT66wGE2hq2EVJSjD1SVsY+/wEhQXb/vrbjkFQ4Wm0Wi//GsUPuRZSSYObLsgSnXw39z42dPGMRwK3/ioP1QTKaLYvRgeVlwiF+aZIgNZWWdMUVL8UjTyXOLpFwdr1Cc9L1qjtfEMUC8Vt9qjnOH+HSyhvVkt5sKz5f/Bv/B+kmWGKSVEXZC/uQCMQOMwYRW1xE5feWV0vj+wr/hFliTHTgb7MsKU7edrCaeBOxqh5QEu/XtZdZqU0YxugE81lMHalv2IgoqaJqs1wgeUonmPiwD9+AvkVUdS2DE6OeMJzpHe2c4+KWN3JSj4XvExlwJ4Vl1dYU6VbzdJODjcY1uR3yOIIyXklWBE8QUPZi0FcMqerF2KMk6yrB4XTulwDvwOts9OgF/L+QmgRSb0bxplZLaPP0dgYT8SZgveCfs09Gx9UYmcpiRpHI7X7yPe9tGC93/nMCgTr4qyqFuoARzQF1tCAakLYZo/FlsPnqTY5Xwzd//s3Lz87G7qbZMO7Ir+Zt4VOqtluL+bjvM6BkdkRqKxZtKjNPFEqFz9ax6g2p/ZE5/xQN//qeQOHww2P+kjf4dAZrQXN66pOfQ4geOt9z4JZIsCOX7ZL/4q5x2AGg+49NO32Enwd1rP2C0d1PRX4K9WIWdEKO/uUWC//oEgchfqtlIr05tiXb0fqWyyYGAd9nB6f8c5U67FObKAa66ns1CPdB0497vTT6WjLYQz+jsDg/oZ+kAqIR0VRkfeExYwHFZWLcOPgAPuMBhI5ZTGRjxWO/TWkOfu8RUE7DEpeApkcI++fpmR+twLgNMpn17jrJXpAc+2Auie0V5hbn+O2wbOIaJlvfakHX/YQ+xYa74PnTGMzh4JuH7Bg1oQpi0LH4MVb2h0hoD8VM8EkwXHQh 4pHY63R7 7gOYdfpEgcSdxulBsdVhI0hgVj0zxoW2anzkGXCDIT9vRzdec9+hGH7ndRj07eTEOpiLgRNzlVkzB83wCUj/aB3wAhLqR3G7z7T9BHt87uAivEOwnNvypLc4FSRMO/CjXuY52SpNRhOYOhplOGDlQ7F2b5Ow246BUEnF8TxOEJHZO/gZxckPt4Xzax6Y/l8wysiVI5yBLapY8CbMPhb/V43kH0zYo5LBmO02dmhqpDoVU0gM= 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 Tue, Nov 19, 2024 at 01:52:00PM +0100, Jann Horn wrote: > > 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. First important thing is that we snapshot the page. So while we may have a torn snapshot of the page, it can't change under us any more, so we don't have to worry about it being swizzled one way and then swizzled back. Second thing is that I think using folio_mapping() is actually wrong. We don't want the swap mapping if it's an anon page that's in the swapcache. We'd be fine just doing mapping = folio->mapping (we'd need to add a check for movable, but I think that's fine). Anyway, we know the folio isn't ksm or anon at the point that we call dump_mapping() because there's a chain of "else" statements. So I think we're fine because we can't switch between anon & file while holding a refcount. Having a refcount on the folio will prevent the folio from being allocated to anything else again. It will not protect the mapping from being torn down (the folio can be truncated from the mapping, then the mapping can be freed, and the memory reused). As you say, the dentry can be renamed as well. This patch series makes me nervous. I'd rather see it done as a bpf script or drgn script, but if it is going to be done in C, I'd really like to see more auditing of the safety here. It feels like the kind of hack that one deploys internally to debug a hard-to-hit condition, rather than the kind of code that we like to ship upstream.