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 B7A61C47DA2 for ; Wed, 17 Jan 2024 12:53:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F3CCA6B00AF; Wed, 17 Jan 2024 07:53:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EEBDB6B00BB; Wed, 17 Jan 2024 07:53:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DDB4D6B00BE; Wed, 17 Jan 2024 07:53:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id CF28E6B00AF for ; Wed, 17 Jan 2024 07:53:33 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A8771160BD5 for ; Wed, 17 Jan 2024 12:53:33 +0000 (UTC) X-FDA: 81688794306.03.0A9EB74 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf20.hostedemail.com (Postfix) with ESMTP id 59BBE1C001E for ; Wed, 17 Jan 2024 12:53:30 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="S7cFgmL/"; spf=pass (imf20.hostedemail.com: domain of brauner@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705496012; a=rsa-sha256; cv=none; b=Gr3rrTnIRcYVkRuqRtUgmtO3iLoXCL2EBT/Vsv/ljjukSdZT3JW38hRy0OsCXtxqfJXx9s K6jAcpfxMV+sH+RYV1xpc8cUxu/gAylmnwHymw6DklgrKxpADZ17npCm0lMbcZFKHP6M17 X5Ws7ehH7QdfWEOO5OiK1ERCrbTUtxc= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="S7cFgmL/"; spf=pass (imf20.hostedemail.com: domain of brauner@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705496012; 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=Ftwj4+breeUhuLZSjvJNyNkzHTK0OyPGEU4KtzvG3J8=; b=O+vKzaHpeLoWfw2c2Ms8a1ZlA3jGfDDsRyEihN8WpwKzR3wkW43Abm8FpVcWk1bagBem3l YwKu4v1pjr5o1roEqkBu4FWmEGG9F/psYElODziphw/IaH6Q4jyMDIwUCQ0Sk5G67iTGYC wkglZYpa+4hT352kLRDRk1wH44E8Cc4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 108B7CE19A2; Wed, 17 Jan 2024 12:53:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 87B42C433F1; Wed, 17 Jan 2024 12:53:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1705496005; bh=hWAj3YQZH9p33cTAw36cmAlNwzzD/NP4yLUNIW0Rh8k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=S7cFgmL/Wat6jQr1sryT918dhwArrwTVsHZTTpB6gowV80fyko3TIJkRMK4U9lEtG qRjg0U8ICgd2FGleVLcrEF1vp4EpYWMFgoLZgRc9Uyqmjyk3rEflh6A2zX1EEuCo4Y adxPAUWA5BsKyc4fmQ1XaU+Ordr0IPkMcp4z1do+FiqG2l6Ecx83v7b20pJMWfgrwS xp5zMAhdDlLYXw2EGbyD4rXWm2DrNPXf1jdr58NeI3loGrFLZ/EGwOuFHU45V1b+Fo wh3l6QxCoqx0RKcxEMLCAR0Uhr/SoRrD9CkIHnDcOYBJevlfE5+5Zdop1qH1OC2o6a 9kOAlXToAngog== Date: Wed, 17 Jan 2024 13:53:20 +0100 From: Christian Brauner To: Jan Kara Cc: 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, Matthew Wilcox , Christoph Hellwig Subject: Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs Message-ID: <20240117-tupfen-unqualifiziert-173af9bc68c8@brauner> References: <20240116-tagelang-zugnummer-349edd1b5792@brauner> <20240116114519.jcktectmk2thgagw@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240116114519.jcktectmk2thgagw@quack3> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 59BBE1C001E X-Stat-Signature: pcdgwgr17rco1qkp9f4mj347dqptwggd X-Rspam-User: X-HE-Tag: 1705496010-964131 X-HE-Meta: U2FsdGVkX1+//QyLN/enWB77WgX1qCsl2OSG/69Yvr26f18plL79+otpvFs14uxM1+c2kaRqJs0X+qkvfLoz7VAar+kkQD/5sy8TaskUxQYDL+1ZdyW8H8DgoMEaKo7VorXeOiMWeOFhDSUY02DrZGlfoQTLPLIBQkQ7ETay5Grujw/iZAJwiWaX8EWlS2ZN9DhsOp0sruxldyud8Yk6ndvVIdXaIa2Djia1aL0B9jrpQi9WoErirjkRcPu2zGR1CDYUzITLN+Wo+UePILsQf0hk3igtIIwk171iYGuOQlIgJaN049yf5FA8qH+z4yHgvejODNdJJTCO7FxUsjJ+/yl6fZAr2BiLlA49qR+GXj3nnQ3vcxAN3A9QEKp7zwttxRiSrG8FX9P24BNdlHTgxeYGzvpxNbYG/QkJGR41GBiwn67QzT+tcb9ynRYxrPGTTHsJhZySBBc3GBmhqJd1apHeWu8PMzWuvhSY/oVM3MOkZcf5a0Sa0pV5LI3KyD84shTLBPu0j0mXntATG7I6HhnVnNRE9JgoqCcTMeXXByEtREYo7yBgVF27XQKr03+YomOBTp+hZybFI6+vd6JrKU6bV6TrjDcngn2D9BmYZK+tcV7HWJ2l62Jrgvo4mTDlIYuZfGsy5IvI7NMZSvw4Ixjqt3c2LH+T2x/avVWCvnIjXQ4BCwnocvf1StvittLTRK46GBKoxoWYhgoes52pJ4c8KWOcWN7G8i4hFazOi7z213Bn8exQDmFp0P156VBlYjrJMYdbAQgFMUXcCmQ+m7S0lh/37n0CJNMSPI4WGFVEyHlyU4mM92Yh2+99HRiAHaq9f6VFQOKvbCdbG/hFATKpoJRp31FSZ+92tdNCjTtbHA8nIisS6XlFD6hZlIabEE3f49zXocuEBa4OFst2BoRA4cq7EXmxwYBNRAAgq6TooxDWrnwRO3yNkVuC5//a+bxPo3ImvzKBSz6NB+V FEP0epiO cCQIMlKFwaQznqPmaO3DlxIkBG+G12KDU9NPD+D/SJS79BVCAVH0EzoQ+xR0JIHXxqYL+iHlx29Kobges7DQannq8bWy/rf7e8sN/XwnQbGlyGpplfFjlInTnkCasYCm868Ry3uZ+IZq7OM7v4asslKoAQIfvJQtwU2V7nPMo+FS9WuKWzmusPafFlQ== 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, Jan 16, 2024 at 12:45:19PM +0100, Jan Kara wrote: > On Tue 16-01-24 11:50:32, Christian Brauner wrote: > > > > > My initial reaction is to give userspace an API to drop the page cache > > of a specific filesystem which may have additional uses. I initially had > > started drafting an ioctl() and then got swayed towards a > > posix_fadvise() flag. I found out that this was already proposed a few > > years ago but got rejected as it was suspected this might just be > > someone toying around without a real world use-case. I think this here > > might qualify as a real-world use-case. > > > > This may at least help securing users with a regular dm-crypt setup > > where dm-crypt is the top layer. Users that stack additional layers on > > top of dm-crypt may still leak plaintext of course if they introduce > > additional caching. But that's on them. > > Well, your usecase has one substantial difference from drop_caches. You > actually *require* pages to be evicted from the page cache for security > purposes. And giving any kind of guarantees is going to be tough. Think for > example when someone grabs page cache folio reference through vmsplice(2), > then you initiate your dmSuspend and want to evict page cache. What are you > going to do? You cannot free the folio while the refcount is elevated, you > could possibly detach it from the page cache so it isn't at least visible > but that has side effects too - after you resume the folio would remain > detached so it will not see changes happening to the file anymore. So IMHO > the only thing you could do without problematic side-effects is report > error. Which would be user unfriendly and could be actually surprisingly > frequent due to trasient folio references taken by various code paths. I wonder though, if you start suspending userspace and the filesystem how likely are you to encounter these transient errors? > > Sure we could report error only if the page has pincount elevated, not only > refcount, but it needs some serious thinking how this would interact. > > Also what is going to be the interaction with mlock(2)? > > Overall this doesn't seem like "just tweak drop_caches a bit" kind of > work... So when I talked to the Gnome people they were interested in an optimal or a best-effort solution. So returning an error might actually be useful. I'm specifically put this here because my knowledge of the page cache isn't sufficient to make a judgement what guarantees are and aren't feasible. So I'm grateful for any insight here.