All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Jan Kara <jack@suse.cz>,
	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 <hch@infradead.org>
Subject: Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs
Date: Thu, 18 Jan 2024 15:26:58 +0100	[thread overview]
Message-ID: <20240118-lodern-einwohner-4b94d4153fd4@brauner> (raw)
In-Reply-To: <ZafpsO3XakIekWXx@casper.infradead.org>

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

  parent reply	other threads:[~2024-01-18 14:27 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-16 10:50 [LSF/MM/BPF TOPIC] Dropping page cache of individual fs Christian Brauner
2024-01-16 11:45 ` Jan Kara
2024-01-17 12:53   ` Christian Brauner
2024-01-17 14:35     ` Jan Kara
2024-01-17 14:52       ` Matthew Wilcox
2024-01-17 20:51         ` Phillip Susi
2024-01-17 20:58           ` Matthew Wilcox
2024-01-18 14:26         ` Christian Brauner [this message]
2024-01-30  0:13         ` Adrian Vovk
2024-02-15 13:57           ` Jan Kara
2024-02-15 19:46             ` Adrian Vovk
2024-02-15 23:17               ` Dave Chinner
2024-02-16  1:14                 ` Adrian Vovk
2024-02-16 20:38                   ` init_on_alloc digression: " John Hubbard
2024-02-16 21:11                     ` Adrian Vovk
2024-02-16 21:19                       ` John Hubbard
2024-01-16 15:25 ` James Bottomley
2024-01-16 15:40   ` Matthew Wilcox
2024-01-16 15:54     ` James Bottomley
2024-01-16 20:56 ` Dave Chinner
2024-01-17  6:17   ` Theodore Ts'o
2024-01-30  1:14     ` Adrian Vovk
2024-01-17 13:19   ` Christian Brauner
2024-01-17 22:26     ` Dave Chinner
2024-01-18 14:09       ` Christian Brauner
2024-02-05 17:39     ` Russell Haley
2024-02-17  4:04 ` Kent Overstreet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240118-lodern-einwohner-4b94d4153fd4@brauner \
    --to=brauner@kernel.org \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.