All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>
Cc: Jeff Layton <jlayton@kernel.org>,
	Josef Bacik <josef@toxicpanda.com>,
	Christoph Hellwig <hch@lst.de>,
	David Howells <dhowells@redhat.com>, Jens Axboe <axboe@kernel.dk>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org
Subject: [PATCH 3/4] fsnotify: assert that file_start_write() is not held in permission hooks
Date: Thu,  7 Dec 2023 14:38:24 +0200	[thread overview]
Message-ID: <20231207123825.4011620-4-amir73il@gmail.com> (raw)
In-Reply-To: <20231207123825.4011620-1-amir73il@gmail.com>

filesystem may be modified in the context of fanotify permission events
(e.g. by HSM service), so assert that sb freeze protection is not held.

If the assertion fails, then the following deadlock would be possible:

CPU0				CPU1			CPU2
-------------------------------------------------------------------------
file_start_write()#0
...
  fsnotify_perm()
    fanotify_get_response() =>	(read event and fill file)
				...
				...			freeze_super()
				...			  sb_wait_write()
				...
				vfs_write()
				  file_start_write()#1

This example demonstrates a use case of an hierarchical storage management
(HSM) service that uses fanotify permission events to fill the content of
a file before access, while a 3rd process starts fsfreeze.

This creates a circular dependeny:
  file_start_write()#0 => fanotify_get_response =>
    file_start_write()#1 =>
      sb_wait_write() =>
        file_end_write()#0

Where file_end_write()#0 can never be called and none of the threads can
make progress.

The assertion is checked for both MAY_READ and MAY_WRITE permission
hooks in preparation for a pre-modify permission event.

The assertion is not checked for an open permission event, because
do_open() takes mnt_want_write() in O_TRUNC case, meaning that it is not
safe to write to filesystem in the content of an open permission event.

Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
 include/linux/fsnotify.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
index 926bb4461b9e..0a9d6a8a747a 100644
--- a/include/linux/fsnotify.h
+++ b/include/linux/fsnotify.h
@@ -107,6 +107,13 @@ static inline int fsnotify_file_perm(struct file *file, int perm_mask)
 {
 	__u32 fsnotify_mask = FS_ACCESS_PERM;
 
+	/*
+	 * filesystem may be modified in the context of permission events
+	 * (e.g. by HSM filling a file on access), so sb freeze protection
+	 * must not be held.
+	 */
+	lockdep_assert_once(file_write_not_started(file));
+
 	if (!(perm_mask & MAY_READ))
 		return 0;
 
-- 
2.34.1


  parent reply	other threads:[~2023-12-07 12:38 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-07 12:38 [PATCH 0/4] Prepare for fsnotify pre-content permission events Amir Goldstein
2023-12-07 12:38 ` [PATCH 1/4] fs: use splice_copy_file_range() inline helper Amir Goldstein
2023-12-08 17:33   ` Christian Brauner
2023-12-10 10:07     ` Amir Goldstein
2023-12-08 18:27   ` Jan Kara
2023-12-07 12:38 ` [PATCH 2/4] fsnotify: split fsnotify_perm() into two hooks Amir Goldstein
2023-12-08 18:33   ` Jan Kara
2023-12-07 12:38 ` Amir Goldstein [this message]
2023-12-08 18:46   ` [PATCH 3/4] fsnotify: assert that file_start_write() is not held in permission hooks Jan Kara
2023-12-08 21:02     ` Amir Goldstein
2023-12-11 10:30       ` Jan Kara
2023-12-11 10:57         ` Amir Goldstein
2023-12-07 12:38 ` [PATCH 4/4] fsnotify: pass access range in file " Amir Goldstein
2023-12-08 17:52   ` Christian Brauner
2023-12-08 18:53   ` Jan Kara
2023-12-08 21:34     ` Amir Goldstein
2023-12-10 13:24       ` Amir Goldstein
2023-12-11 11:49         ` Jan Kara
2023-12-11 12:00           ` Amir Goldstein
2023-12-11 14:53             ` Jan Kara
2023-12-07 21:51 ` [PATCH 0/4] Prepare for fsnotify pre-content permission events Josef Bacik
2023-12-08  7:34   ` Amir Goldstein
2023-12-15 17:00     ` Amir Goldstein
2023-12-15 20:04       ` Josef Bacik
2023-12-08 17:54 ` Christian Brauner

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=20231207123825.4011620-4-amir73il@gmail.com \
    --to=amir73il@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=jlayton@kernel.org \
    --cc=josef@toxicpanda.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --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 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.