From: Jan Kara <jack@suse.cz>
To: <linux-fsdevel@vger.kernel.org>
Cc: Amir Goldstein <amir73il@gmail.com>,
Josef Bacik <josef@toxicpanda.com>,
brauner@kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Al Viro <viro@ZenIV.linux.org.uk>,
linux-xfs@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-ext4@vger.kernel.org, linux-mm@kvack.org,
Jan Kara <jack@suse.cz>
Subject: [PATCH 13/19] fanotify: disable readahead if we have pre-content watches
Date: Thu, 21 Nov 2024 12:22:12 +0100 [thread overview]
Message-ID: <20241121112218.8249-14-jack@suse.cz> (raw)
In-Reply-To: <20241121112218.8249-1-jack@suse.cz>
From: Josef Bacik <josef@toxicpanda.com>
With page faults we can trigger readahead on the file, and then
subsequent faults can find these pages and insert them into the file
without emitting an fanotify event. To avoid this case, disable
readahead if we have pre-content watches on the file. This way we are
guaranteed to get an event for every range we attempt to access on a
pre-content watched file.
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Link: https://patch.msgid.link/70a54e859f555e54bc7a47b32fe5aca92b085615.1731684329.git.josef@toxicpanda.com
---
mm/filemap.c | 12 ++++++++++++
mm/readahead.c | 14 ++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/mm/filemap.c b/mm/filemap.c
index 36d22968be9a..98f15dccff89 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -3149,6 +3149,14 @@ static struct file *do_sync_mmap_readahead(struct vm_fault *vmf)
unsigned long vm_flags = vmf->vma->vm_flags;
unsigned int mmap_miss;
+ /*
+ * If we have pre-content watches we need to disable readahead to make
+ * sure that we don't populate our mapping with 0 filled pages that we
+ * never emitted an event for.
+ */
+ if (unlikely(FMODE_FSNOTIFY_HSM(file->f_mode)))
+ return fpin;
+
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
/* Use the readahead code, even if readahead is disabled */
if ((vm_flags & VM_HUGEPAGE) && HPAGE_PMD_ORDER <= MAX_PAGECACHE_ORDER) {
@@ -3217,6 +3225,10 @@ static struct file *do_async_mmap_readahead(struct vm_fault *vmf,
struct file *fpin = NULL;
unsigned int mmap_miss;
+ /* See comment in do_sync_mmap_readahead. */
+ if (unlikely(FMODE_FSNOTIFY_HSM(file->f_mode)))
+ return fpin;
+
/* If we don't want any read-ahead, don't bother */
if (vmf->vma->vm_flags & VM_RAND_READ || !ra->ra_pages)
return fpin;
diff --git a/mm/readahead.c b/mm/readahead.c
index 3dc6c7a128dd..e482f9f2e159 100644
--- a/mm/readahead.c
+++ b/mm/readahead.c
@@ -128,6 +128,7 @@
#include <linux/blk-cgroup.h>
#include <linux/fadvise.h>
#include <linux/sched/mm.h>
+#include <linux/fsnotify.h>
#include "internal.h"
@@ -544,6 +545,15 @@ void page_cache_sync_ra(struct readahead_control *ractl,
unsigned long max_pages, contig_count;
pgoff_t prev_index, miss;
+ /*
+ * If we have pre-content watches we need to disable readahead to make
+ * sure that we don't find 0 filled pages in cache that we never emitted
+ * events for. Filesystems supporting HSM must make sure to not call
+ * this function with ractl->file unset for files handled by HSM.
+ */
+ if (ractl->file && unlikely(FMODE_FSNOTIFY_HSM(ractl->file->f_mode)))
+ return;
+
/*
* Even if readahead is disabled, issue this request as readahead
* as we'll need it to satisfy the requested range. The forced
@@ -622,6 +632,10 @@ void page_cache_async_ra(struct readahead_control *ractl,
if (!ra->ra_pages)
return;
+ /* See the comment in page_cache_sync_ra. */
+ if (ractl->file && unlikely(FMODE_FSNOTIFY_HSM(ractl->file->f_mode)))
+ return;
+
/*
* Same bit is used for PG_readahead and PG_reclaim.
*/
--
2.35.3
next prev parent reply other threads:[~2024-11-21 11:22 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-21 11:21 [PATCH v9 00/19] fanotify: add pre-content hooks Jan Kara
2024-11-21 11:22 ` [PATCH 01/19] fs: get rid of __FMODE_NONOTIFY kludge Jan Kara
2024-11-21 11:22 ` [PATCH 02/19] fsnotify: opt-in for permission events at file open time Jan Kara
2024-11-21 11:22 ` [PATCH 03/19] fsnotify: check if file is actually being watched for pre-content events on open Jan Kara
2024-11-21 16:01 ` Amir Goldstein
2024-11-22 10:58 ` Jan Kara
2024-11-21 11:22 ` [PATCH 04/19] fanotify: don't skip extra event info if no info_mode is set Jan Kara
2024-11-21 11:22 ` [PATCH 05/19] fanotify: rename a misnamed constant Jan Kara
2024-11-21 11:22 ` [PATCH 06/19] fanotify: reserve event bit of deprecated FAN_DIR_MODIFY Jan Kara
2024-11-21 11:22 ` [PATCH 07/19] fsnotify: introduce pre-content permission events Jan Kara
2024-11-21 11:22 ` [PATCH 08/19] fsnotify: pass optional file access range in pre-content event Jan Kara
2024-11-21 11:22 ` [PATCH 09/19] fsnotify: generate pre-content permission event on truncate Jan Kara
2024-11-21 11:22 ` [PATCH 10/19] fanotify: introduce FAN_PRE_ACCESS permission event Jan Kara
2024-11-21 11:22 ` [PATCH 11/19] fanotify: report file range info with pre-content events Jan Kara
2024-11-21 11:22 ` [PATCH 12/19] fanotify: allow to set errno in FAN_DENY permission response Jan Kara
2024-11-21 11:22 ` Jan Kara [this message]
2024-11-21 11:22 ` [PATCH 14/19] mm: don't allow huge faults for files with pre content watches Jan Kara
2024-11-21 11:22 ` [PATCH 15/19] fsnotify: generate pre-content permission event on page fault Jan Kara
2024-11-21 11:22 ` [PATCH 16/19] xfs: add pre-content fsnotify hook for DAX faults Jan Kara
2024-11-21 11:22 ` [PATCH 17/19] btrfs: disable defrag on pre-content watched files Jan Kara
2024-11-21 11:22 ` [PATCH 18/19] ext4: add pre-content fsnotify hook for DAX faults Jan Kara
2024-11-21 11:22 ` [PATCH 19/19] fs: enable pre-content events on supported file systems Jan Kara
2024-11-21 16:06 ` [PATCH v9 00/19] fanotify: add pre-content hooks Amir Goldstein
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=20241121112218.8249-14-jack@suse.cz \
--to=jack@suse.cz \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox