Linux XFS filesystem development
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Jan Kara <jack@suse.cz>, Josef Bacik <josef@toxicpanda.com>,
	kernel-team@fb.com, linux-fsdevel@vger.kernel.org,
	amir73il@gmail.com, brauner@kernel.org,
	linux-xfs@vger.kernel.org, gfs2@lists.linux.dev,
	linux-bcachefs@vger.kernel.org,
	Dave Chinner <david@fromorbit.com>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH v4 16/16] xfs: add pre-content fsnotify hook for write faults
Date: Mon, 2 Sep 2024 12:23:44 +0200	[thread overview]
Message-ID: <20240902102344.evvpipetu6zghrwz@quack3> (raw)
In-Reply-To: <20240830232833.GR6216@frogsfrogsfrogs>

On Fri 30-08-24 16:28:33, Darrick J. Wong wrote:
> On Thu, Aug 29, 2024 at 01:17:53PM +0200, Jan Kara wrote:
> > On Wed 14-08-24 17:25:34, Josef Bacik wrote:
> > > xfs has it's own handling for write faults, so we need to add the
> > > pre-content fsnotify hook for this case.  Reads go through filemap_fault
> > > so they're handled properly there.
> > > 
> > > Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> > 
> > Looks good to me but it would be great to get explicit ack from some XFS
> > guy...  Some selection CCed :)
> 
> Looks decent to me, but I wonder why xfs_write_fault has to invoke
> filemap_maybe_emit_fsnotify_event itself?  Can that be done from
> whatever calls ->page_mkwrite and friends?

So we were discussing this already here [1]. The options we have:

1) Call filemap_maybe_emit_fsnotify_event() from filesystem hooks
(filemap_fault() for those who use it). This is a bit ugly because it
requires modification to filesystems with their own fault handlers.

2) Call filemap_maybe_emit_fsnotify_event() from generic code before
calling ->fault() and if we needed to send event (and thus dropped
mmap_lock), we will retry the fault. This requires no special fs awareness
but the ->fault hook will then be called after retry most of the times on
HSM managed fs and thus without possibility to drop mmap_lock making
contention there possibly worse.

3) (I don't think we've discussed this option yet): Call
filemap_maybe_emit_fsnotify_event() in generic code before calling ->fault
and then continue to call ->fault even if we've dropped mmap_lock. This
will require changing calling convention for ->fault as vmf->vma must not
be touched after we've dropped mmap_lock and practically all users end up
using it to get vmf->vma->vm_file. With per-fs opt in flag to enable HSM
events this could be manageable but frankly I'm not convinced the
complicated calling convention would be better outcome than 1). But I'm
open for discussion.
								Honza

[1] https://lore.kernel.org/all/CAOQ4uxgXEzT=Buwu8SOkQG+2qcObmdH4NgsGme8bECObiobfTQ@mail.gmail.com
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2024-09-02 10:23 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-14 21:25 [PATCH v4 00/16] fanotify: add pre-content hooks Josef Bacik
2024-08-14 21:25 ` [PATCH v4 01/16] fanotify: don't skip extra event info if no info_mode is set Josef Bacik
2024-08-14 21:25 ` [PATCH v4 02/16] fsnotify: introduce pre-content permission event Josef Bacik
2024-08-14 21:25 ` [PATCH v4 03/16] fsnotify: generate pre-content permission event on open Josef Bacik
2024-08-14 21:25 ` [PATCH v4 04/16] fanotify: introduce FAN_PRE_ACCESS permission event Josef Bacik
2024-08-14 21:25 ` [PATCH v4 05/16] fanotify: introduce FAN_PRE_MODIFY " Josef Bacik
2024-08-14 21:25 ` [PATCH v4 06/16] fanotify: pass optional file access range in pre-content event Josef Bacik
2024-08-14 21:25 ` [PATCH v4 07/16] fanotify: rename a misnamed constant Josef Bacik
2024-08-14 21:25 ` [PATCH v4 08/16] fanotify: report file range info with pre-content events Josef Bacik
2024-08-29 10:13   ` Jan Kara
2024-08-14 21:25 ` [PATCH v4 09/16] fanotify: allow to set errno in FAN_DENY permission response Josef Bacik
2024-08-29 10:25   ` Jan Kara
2024-08-14 21:25 ` [PATCH v4 10/16] fanotify: add a helper to check for pre content events Josef Bacik
2024-08-14 21:25 ` [PATCH v4 11/16] fanotify: disable readahead if we have pre-content watches Josef Bacik
2024-08-29 10:48   ` Jan Kara
2024-08-29 12:44     ` Josef Bacik
2024-08-14 21:25 ` [PATCH v4 12/16] mm: don't allow huge faults for files with pre content watches Josef Bacik
2024-08-29 10:51   ` Jan Kara
2024-08-14 21:25 ` [PATCH v4 13/16] fsnotify: generate pre-content permission event on page fault Josef Bacik
2024-08-29 11:07   ` Jan Kara
2024-08-14 21:25 ` [PATCH v4 14/16] bcachefs: add pre-content fsnotify hook to fault Josef Bacik
2024-08-29 11:10   ` Jan Kara
2024-08-29 11:26     ` Kent Overstreet
2024-08-29 12:46       ` Josef Bacik
2024-08-29 12:55         ` Kent Overstreet
2024-08-29 12:25     ` Kent Overstreet
2024-08-14 21:25 ` [PATCH v4 15/16] gfs2: " Josef Bacik
2024-08-29 11:15   ` Jan Kara
2024-08-29 11:26     ` Amir Goldstein
2024-08-29 11:43       ` Jan Kara
2024-08-29 12:49         ` Amir Goldstein
2024-08-29 12:42     ` Josef Bacik
2024-08-14 21:25 ` [PATCH v4 16/16] xfs: add pre-content fsnotify hook for write faults Josef Bacik
2024-08-29 11:17   ` Jan Kara
2024-08-30 23:28     ` Darrick J. Wong
2024-09-02 10:23       ` Jan Kara [this message]
2024-09-02 11:19         ` Christian Brauner
2024-08-29 21:41 ` [PATCH v4 00/16] fanotify: add pre-content hooks Darrick J. Wong
2024-08-30  8:55   ` Amir Goldstein
2024-08-30 23:22     ` Darrick J. Wong

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=20240902102344.evvpipetu6zghrwz@quack3 \
    --to=jack@suse.cz \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=gfs2@lists.linux.dev \
    --cc=hch@infradead.org \
    --cc=josef@toxicpanda.com \
    --cc=kernel-team@fb.com \
    --cc=linux-bcachefs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox