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 2BCF9C4707B for ; Thu, 18 Jan 2024 14:27:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9AC016B007D; Thu, 18 Jan 2024 09:27:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 95B1C6B007E; Thu, 18 Jan 2024 09:27:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 823256B0085; Thu, 18 Jan 2024 09:27:12 -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 6D7046B007D for ; Thu, 18 Jan 2024 09:27:12 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3819E80710 for ; Thu, 18 Jan 2024 14:27:12 +0000 (UTC) X-FDA: 81692659104.17.4B8905E Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf19.hostedemail.com (Postfix) with ESMTP id DF9821A0003 for ; Thu, 18 Jan 2024 14:27:09 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HH2RHRMN; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf19.hostedemail.com: domain of brauner@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705588030; 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=rhREg/cvLt7zu3UydZ6RZteI12dsFjQKDmWdJkD5KRQ=; b=lReYB/9KvQhJ1goc/aUWJ/JBFIb6aWY+AkRDS3nLR9lPW988xm+YScQ2do41jTveZRMNg2 zWYHnu8b5aiEItoSli7TvJXxs+50va+VppvEuQUr6TKgTDPYPt/KVlryU9ZvF/FV3lTY7L hmEVD3Mu7mxHyIdux0wWI7BGZ8LPbDQ= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HH2RHRMN; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf19.hostedemail.com: domain of brauner@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705588030; a=rsa-sha256; cv=none; b=mvz0ZJZNlRnhVY4eLq7OTN6rHNE7zGdxXIshygvDhVI3ieWTv40iw7Pouhw+vJ6DCifZgj v18U6ssc/51YfH0n882gAHCEn5I8tudL518rNFyG8VQQTN5TbWQIufGqHhQksPG8KcpY2X +PRjRbg1FA06VMSj1HdoUr44QuZdytk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 43F58CE1FD1; Thu, 18 Jan 2024 14:27:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74FBBC433C7; Thu, 18 Jan 2024 14:27:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1705588023; bh=YmGrZjWGN6bhVc62uzAhw2r6YpLLQ2rytwNdVlCo1/M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HH2RHRMN+Y7+lj4he2mWElpSDJ0MublcMwlr55tUM8QobMsA6lNCoeYvWviSAOOUW BtTxP2ba+8RN6ZGheqMnxTjTa+0OmZ5S730EKWDtXRSZgvaIY+r3r9jj6mbFJmPz91 FMm3HgnYKa18q02+fWR93xSVJVLWvUbdLJpWPfzpyTdCO1J/oeEm9hZ2NgIq7REmRN RMcT9mcamKsvr0SB89zW2x1wg3tNawoghLeJX5ROKQE3+xTbXsSEyzvPOxkCpawdag ougFQkrQs7ZtfAlTsHaKwu2oWJgvfNtnhmQLF12gwtyBZo1paXJAZGDo6AwQ2s0NWo mcfvAH4Hb7X+g== Date: Thu, 18 Jan 2024 15:26:58 +0100 From: Christian Brauner To: Matthew Wilcox Cc: Jan Kara , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-btrfs@vger.kernel.org, linux-block@vger.kernel.org, Christoph Hellwig Subject: Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs Message-ID: <20240118-lodern-einwohner-4b94d4153fd4@brauner> References: <20240116-tagelang-zugnummer-349edd1b5792@brauner> <20240116114519.jcktectmk2thgagw@quack3> <20240117-tupfen-unqualifiziert-173af9bc68c8@brauner> <20240117143528.idmyeadhf4yzs5ck@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: DF9821A0003 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: k5t899hepfh8sbj7asdzz6x899rfb6rm X-HE-Tag: 1705588029-912347 X-HE-Meta: U2FsdGVkX1+WZ/9XeFu5+3gMeyC7NmkklTi5YcuPgmKjkBM7yf3szMmOibACaj4Vx7LUyzBqUaHPAwOKGZIyB23cT24ekXaOBQNixBNwSEVGfY2mQRdpSeTkncV1nKS6kSbsipQ6jVBx3zp8mhb8S1iXxX/X8ISZ5F7w8n5/KROiSAnyeQuQvn/4NGlgQP1DDKAoYRdo1fZj7BeiKsQTRiikU+59JXKZMo0y3mNwmGLhN0q5ZckxV+d4kZYoQcZIcGGHKFBmy7Moas3XPMQwbhrjtc25RVydkOUvRAhf+54EMTwJ/Ipyb9y7Yfxp/0VfxoQcPteGeSn2xSa8xHBfoAEta6tvhr59edmECkNN0DJV6cbt388K5IQ/WdsdZTgrgiRxElYcYV4TBbC+wR15Axs9foAKa8nRrgIc0jDs7f4CEhDCwnUXva9o0oU+cINpuWj0jDs2NbSLAurxHKWtYtm7SnzoS0p8gFzykgkTPmKahbPxanwLCOxJOUwTBpmLL5ZVk7PpF8qafnPLiuLcAks00VoOvgN7lHNQNhwCBcsBVPpdKIrU+Avy4CcifRifidmNSRZnKzjIh/Wc+9RVVX8mi8Pz2RDdinwX0Bw4LlDoY71XQLjxc2+14vkpJx9X3Lt6FsU9CftGyUilOD515JnhKLy+UOWPV5EMY1Jxj5IuDB1jRtGjHrHnxetU+EGLP4BmyJK88/uZiWLq1DVPFErhzvlu1dByZ64IvOvT9TsKDFfhT3PVozzh1OFXh/9tSXbhNGxeTJN+t8d3Is+Oyaq4Z+HtVOOESaP5bT/u8J39/s8R4VkcEkRD0W6L/DfYvaw1FFpv7GAt5bG5zQuEblsMwZjPw3GjgQRAl0m48+Fuvwf4CX1/fR93juIm/haSZvO6IjsfwXrojzhuGlLQKwiXDUd3LwCvLH5liwC6OWbQd/RsNWGtWZqHjH5B4uCeICOiSYKkIkgLBAelV6p NI+/EG7k 0A0vAfIMLP0HiKtyU5MZoVncgb4upJz5BKS616rHBMeUnMk5SdxKQaGhUxtK1DWPJXtDbKCphDDAIgDZiikJVCVOj3N7Di9+OQ40stGdELApM3GCb5CpmSUOy2xHpMuOuPHGSTjz51cdLBjl2DFrBd3ctRy6H3tWFLJJT7MoS1AngUBefRmMPLaZWWFUS1HTIhN7d1WvBZxqeIG8b8RsF0YYjy3ZATtnAiO+FIPytPDMWwYQ= 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 Wed, Jan 17, 2024 at 02:52:32PM +0000, Matthew Wilcox wrote: > On Wed, Jan 17, 2024 at 03:35:28PM +0100, Jan Kara wrote: > > OK. So could we then define the effect of your desired call as calling > > posix_fadvise(..., POSIX_FADV_DONTNEED) for every file? This is kind of > > best-effort eviction which is reasonably well understood by everybody. > > I feel like we're in an XY trap [1]. What Christian actually wants is > to not be able to access the contents of a file while the device it's > on is suspended, and we've gone from there to "must drop the page cache". > > We have numerous ways to intercept file reads and make them either > block or fail. The obvious one to me is security_file_permission() > called from rw_verify_area(). Can we do everything we need with an LSM? > > [1] https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem Nice idea and we do stuff like that in other scenarios such as [1] where we care about preventing _writes_ from occuring while a specific service hasn't been fully set up. So that has been going through my mind as well. And the LSM approach might be complementary. For example, if feasible, it could be activated _before_ the freeze operation only allowing the block layer initiated freeze. And then we can drop the page cache. But in this case the LSM approach isn't easily workable or solves the problem for Gnome. It would force the usage of a bpf LSM most likely as well. And the LSM would have to be activated when the filesystem is frozen and then deactivated when it is unfrozen. I'm not even sure that's currently easily doable. But the Gnome use-case wants to be able to drop file contents before they suspend the system. So the thread-model is wider than just someone being able to read contents on an active systems. But it's best-effort of course. So failing and reporting an error would be totally fine and then policy could dictate whether to not even suspend. It actually might help userspace in general. The ability to drop the page cache of a specific filesystem is useful independent of the Gnome use-case especially in systems with thousands or ten-thousands of services that use separate filesystem images something that's not uncommon. [1]: https://github.com/systemd/systemd/blob/74e6a7d84a40de18bb3b18eeef6284f870f30a6e/src/nsresourced/bpf/userns_restrict/userns-restrict.bpf.c