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
>
next prev parent 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