public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: brauner@kernel.org, hch@lst.de, linux-ext4@vger.kernel.org,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	gabriel@krisman.be, amir73il@gmail.com
Subject: Re: [PATCH 2/6] fs: report filesystem and file I/O errors to fsnotify
Date: Tue, 6 Jan 2026 09:35:13 -0800	[thread overview]
Message-ID: <20260106173513.GD191481@frogsfrogsfrogs> (raw)
In-Reply-To: <cunesvp5k37ocmz2nbkdov7ssu3djqvdii26d4gn6sj7sgtnca@b5mokxhvneay>

On Mon, Dec 22, 2025 at 04:36:14PM +0100, Jan Kara wrote:
> On Wed 17-12-25 18:03:11, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > Create some wrapper code around struct super_block so that filesystems
> > have a standard way to queue filesystem metadata and file I/O error
> > reports to have them sent to fsnotify.
> > 
> > If a filesystem wants to provide an error number, it must supply only
> > negative error numbers.  These are stored internally as negative
> > numbers, but they are converted to positive error numbers before being
> > passed to fanotify, per the fanotify(7) manpage.  Implementations of
> > super_operations::report_error are passed the raw internal event data.
> > 
> > Note that we have to play some shenanigans with mempools and queue_work
> > so that the error handling doesn't happen outside of process context,
> > and the event handler functions (both ->report_error and fsnotify) can
> > handle file I/O error messages without having to worry about whatever
> > locks might be held.  This asynchronicity requires that unmount wait for
> > pending events to clear.
> > 
> > Add a new callback to the superblock operations structure so that
> > filesystem drivers can themselves respond to file I/O errors if they so
> > desire.  This will be used for an upcoming self-healing patchset for
> > XFS.
> > 
> > Suggested-by: Christoph Hellwig <hch@lst.de>
> > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> 
> Looks good to me. Besides the nits Christoph commented on just two comments:
> 
> > +static inline struct fserror_event *fserror_alloc_event(struct super_block *sb,
> > +							gfp_t gfp_flags)
> > +{
> > +	struct fserror_event *event = NULL;
> > +
> > +	/*
> > +	 * If pending_errors already reached zero or is no longer active,
> > +	 * the superblock is being deactivated so there's no point in
> > +	 * continuing.
> > +	 */
> > +	if (!refcount_inc_not_zero(&sb->s_pending_errors))
> > +		return NULL;
> 
> It would be good here or in the above comment explicitely mention that the
> ordering of s_pending_errors check and SB_ACTIVE check is mandated by the
> ordering in generic_shutdown_super() and that the barriers are implicitely
> provided by the refcount manipulations here and in fserror_unmount().

Ok.  I'll send a follow-on patch, though I don't see vfs-7.0.fserror on
vfs.git so I'm confused about where things are right now.

> > +	if (!(sb->s_flags & SB_ACTIVE))
> > +		goto out_pending;
> > +
> > +	event = mempool_alloc(&fserror_events_pool, gfp_flags);
> > +	if (!event)
> > +		goto out_pending;
> > +
> > +	/* mempool_alloc doesn't support GFP_ZERO */
> > +	memset(event, 0, sizeof(*event));
> > +	event->sb = sb;
> > +	INIT_WORK(&event->work, fserror_worker);
> > +
> > +	return event;
> > +
> > +out_pending:
> > +	fserror_pending_dec(sb);
> > +	return NULL;
> > +}
> > +
> > +/**
> > + * fserror_report - report a filesystem error of some kind
> > + *
> > + * Report details of a filesystem error to the super_operations::report_error
> > + * callback if present; and to fsnotify for distribution to userspace.  @sb,
> > + * @gfp, @type, and @error must all be specified.  For file I/O errors, the
> > + * @inode, @pos, and @len fields must also be specified.  For file metadata
> > + * errors, @inode must be specified.  If @inode is not NULL, then @inode->i_sb
> > + * must point to @sb.
> > + *
> > + * Reporting work is deferred to a workqueue to ensure that ->report_error is
> > + * called from process context without any locks held.  An active reference to
> > + * the inode is maintained until event handling is complete, and unmount will
> > + * wait for queued events to drain.
> > + *
> > + * @sb:		superblock of the filesystem
> > + * @inode:	inode within that filesystem, if applicable
> > + * @type:	type of error encountered
> > + * @pos:	start of inode range affected, if applicable
> > + * @len:	length of inode range affected, if applicable
> > + * @error:	error number encountered, must be negative
> > + * @gfp:	memory allocation flags for conveying the event to a worker,
> > + *		since this function can be called from atomic contexts
> > + */
> > +void fserror_report(struct super_block *sb, struct inode *inode,
> > +		    enum fserror_type type, loff_t pos, u64 len, int error,
> > +		    gfp_t gfp)
> > +{
> > +	struct fserror_event *event;
> > +
> > +	/* sb and inode must be from the same filesystem */
> > +	WARN_ON_ONCE(inode && inode->i_sb != sb);
> > +
> > +	/* error number must be negative */
> > +	WARN_ON_ONCE(error >= 0);
> 
> Since the error reporting is kind of expensive now (allocation & queueing
> work) it would be nice to check somebody actually cares about the error
> events at all. We can provide a helper from fsnotify for that, I'm not sure
> about ->report_error hook since it didn't get used in this series at all in
> the end...

I didn't quite get to posting that patchset before vacation, but it's
posted now in "xfs: convey file I/O errors to the health monitor":

https://lore.kernel.org/linux-fsdevel/176766637421.774337.94510884010750487.stgit@frogsfrogsfrogs/T/#Z2e.:..:176766637421.774337.94510884010750487.stgit::40frogsfrogsfrogs:1fs:xfs:xfs_super.c

--D
> 
> 								Honza
> -- 
> Jan Kara <jack@suse.com>
> SUSE Labs, CR
> 

  reply	other threads:[~2026-01-06 17:35 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-18  2:02 [PATCHSET V4 1/2] fs: generic file IO error reporting Darrick J. Wong
2025-12-18  2:02 ` [PATCH 1/6] uapi: promote EFSCORRUPTED and EUCLEAN to errno.h Darrick J. Wong
2025-12-18  5:17   ` Christoph Hellwig
2025-12-18 11:04     ` Alejandro Colomar
2025-12-18 18:45       ` Darrick J. Wong
2025-12-18  9:33   ` Gao Xiang
2025-12-22 15:01   ` Jan Kara
2025-12-18  2:03 ` [PATCH 2/6] fs: report filesystem and file I/O errors to fsnotify Darrick J. Wong
2025-12-18  5:21   ` Christoph Hellwig
2025-12-18 18:44     ` Darrick J. Wong
2025-12-24 12:29       ` Christian Brauner
2026-01-06 16:42         ` Darrick J. Wong
2026-01-12 13:17           ` Christian Brauner
2026-01-12 18:50             ` Darrick J. Wong
2025-12-18 23:32   ` [PATCH V4.1 " Darrick J. Wong
2025-12-22 15:36   ` [PATCH " Jan Kara
2026-01-06 17:35     ` Darrick J. Wong [this message]
2025-12-18  2:03 ` [PATCH 3/6] iomap: report file I/O errors to the VFS Darrick J. Wong
2025-12-18  5:22   ` Christoph Hellwig
2025-12-22 15:30   ` Jan Kara
2025-12-18  2:03 ` [PATCH 4/6] xfs: report fs metadata errors via fsnotify Darrick J. Wong
2025-12-18  5:22   ` Christoph Hellwig
2025-12-18  2:03 ` [PATCH 5/6] xfs: translate fsdax media errors into file "data lost" errors when convenient Darrick J. Wong
2025-12-18  5:23   ` Christoph Hellwig
2025-12-18  2:04 ` [PATCH 6/6] ext4: convert to new fserror helpers Darrick J. Wong
2025-12-18  5:23   ` Christoph Hellwig
2025-12-22 15:34   ` Jan Kara
2026-01-06 17:30     ` Darrick J. Wong
2026-01-06 23:33 ` [PATCH 7/6] fs: improve comment in fserror_alloc_event Darrick J. Wong
2026-01-07  9:19   ` Jan Kara
  -- strict thread matches above, loose matches on Subject: below --
2026-01-13  0:31 [PATCHSET v5] fs: generic file IO error reporting Darrick J. Wong
2026-01-13  0:31 ` [PATCH 2/6] fs: report filesystem and file I/O errors to fsnotify Darrick J. Wong
2026-01-13  8:24   ` Christoph Hellwig

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=20260106173513.GD191481@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=gabriel@krisman.be \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=linux-ext4@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