From: "Darrick J. Wong" <djwong@kernel.org>
To: Zorro Lang <zlang@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
jack@suse.cz, fstests@vger.kernel.org, amir73il@gmail.com,
gabriel@krisman.be, linux-fsdevel@vger.kernel.org,
linux-xfs@vger.kernel.org, hch@lst.de
Subject: Re: [PATCH 1/1] generic: test fsnotify filesystem error reporting
Date: Mon, 16 Mar 2026 15:16:58 -0700 [thread overview]
Message-ID: <20260316221658.GO6069@frogsfrogsfrogs> (raw)
In-Reply-To: <20260316184041.ji5slfx4yvtfwwzq@doltdoltdolt>
On Tue, Mar 17, 2026 at 02:40:41AM +0800, Zorro Lang wrote:
> On Mon, Mar 16, 2026 at 09:21:47AM -0700, Darrick J. Wong wrote:
> > On Mon, Mar 16, 2026 at 02:08:11AM -0700, Christoph Hellwig wrote:
> > > On Mon, Mar 09, 2026 at 08:50:08PM -0700, Darrick J. Wong wrote:
> > > > From: Darrick J. Wong <djwong@kernel.org>
> > > >
> > > > Test the fsnotify filesystem error reporting.
> > >
> > > Still would be helpful to explain what is being tested and how and
> > > the source of the test tool.
> >
> > "Use dmerror to inject a media error for a file's storage, then run some
> > IO and make sure that fanotify reports the IO errors."
> >
> > (I'm not sure what the process is for updating commit messages once
> > something's in patches-in-queue...)
>
> patches-in-queue is a scratch branch, I always re-push(-f) to this branch.
> So please feel free to tell me what do you want to update in this patch
> (I'm going to make the next fstests release soon:).
Just the two changes I've mentioned so far in the threads, please.
I've more fixes to make to these tests, so I'll send those patches
shortly.
--D
> Thanks,
> Zorro
>
> >
> > > > +#ifndef FILEID_INO32_GEN
> > > > +#define FILEID_INO32_GEN 1
> > > > +#endif
> > > > +
> > > > +#ifndef FILEID_INVALID
> > > > +#define FILEID_INVALID 0xff
> > > > +#endif
> > > > +
> > > > +static void print_fh(struct file_handle *fh)
> > > > +{
> > > > + int i;
> > > > + uint32_t *h = (uint32_t *) fh->f_handle;
> > > > +
> > > > + printf("\tfh: ");
> > > > + for (i = 0; i < fh->handle_bytes; i++)
> > > > + printf("%hhx", fh->f_handle[i]);
> > > > + printf("\n");
> > > > +
> > > > + printf("\tdecoded fh: ");
> > > > + if (fh->handle_type == FILEID_INO32_GEN)
> > > > + printf("inode=%u gen=%u\n", h[0], h[1]);
> > > > + else if (fh->handle_type == FILEID_INVALID && !fh->handle_bytes)
> > > > + printf("Type %d (Superblock error)\n", fh->handle_type);
> > > > + else
> > > > + printf("Type %d (Unknown)\n", fh->handle_type);
> > >
> > >
> > > Isn't this always going to print unknown for normal xfs mounts without
> > > inode32?
> >
> > Yes, though generic/791 filters out the file handle and (TBH) I don't
> > really want people getting ideas about cracking file handles. Probably
> > we should just eliminate this whole part of the function, but that would
> > make future forklift upgrades from the kernel harder.
> >
> > --D
> >
>
next prev parent reply other threads:[~2026-03-16 22:16 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-10 3:38 [PATCHBOMB v9] xfsprogs: autonomous self healing of filesystems Darrick J. Wong
2026-03-10 3:42 ` [PATCHSET v9 1/2] fstests: test generic file IO error reporting Darrick J. Wong
2026-03-10 3:50 ` [PATCH 1/1] generic: test fsnotify filesystem " Darrick J. Wong
2026-03-10 7:07 ` Amir Goldstein
2026-03-13 18:01 ` Zorro Lang
2026-03-13 23:27 ` Darrick J. Wong
2026-03-16 9:08 ` Christoph Hellwig
2026-03-16 16:21 ` Darrick J. Wong
2026-03-16 18:40 ` Zorro Lang
2026-03-16 22:16 ` Darrick J. Wong [this message]
2026-03-17 3:43 ` Zorro Lang
2026-03-10 3:42 ` [PATCHSET v9 2/2] fstests: autonomous self healing of filesystems Darrick J. Wong
2026-03-10 3:50 ` [PATCH 01/14] xfs: test health monitoring code Darrick J. Wong
2026-03-13 18:18 ` Zorro Lang
2026-03-10 3:50 ` [PATCH 02/14] xfs: test for metadata corruption error reporting via healthmon Darrick J. Wong
2026-03-13 18:35 ` Zorro Lang
2026-03-10 3:50 ` [PATCH 03/14] xfs: test io " Darrick J. Wong
2026-03-13 18:53 ` Zorro Lang
2026-03-10 3:51 ` [PATCH 04/14] xfs: set up common code for testing xfs_healer Darrick J. Wong
2026-03-13 19:04 ` Zorro Lang
2026-03-14 20:37 ` Zorro Lang
2026-03-15 4:51 ` Darrick J. Wong
2026-03-10 3:51 ` [PATCH 05/14] xfs: test xfs_healer's event handling Darrick J. Wong
2026-03-13 19:19 ` Zorro Lang
2026-03-10 3:51 ` [PATCH 06/14] xfs: test xfs_healer can fix a filesystem Darrick J. Wong
2026-03-13 19:28 ` Zorro Lang
2026-03-10 3:51 ` [PATCH 07/14] xfs: test xfs_healer can report file I/O errors Darrick J. Wong
2026-03-13 19:32 ` Zorro Lang
2026-03-10 3:52 ` [PATCH 08/14] xfs: test xfs_healer can report file media errors Darrick J. Wong
2026-03-13 19:36 ` Zorro Lang
2026-03-10 3:52 ` [PATCH 09/14] xfs: test xfs_healer can report filesystem shutdowns Darrick J. Wong
2026-03-13 19:45 ` Zorro Lang
2026-03-10 3:52 ` [PATCH 10/14] xfs: test xfs_healer can initiate full filesystem repairs Darrick J. Wong
2026-03-13 19:48 ` Zorro Lang
2026-03-10 3:52 ` [PATCH 11/14] xfs: test xfs_healer can follow mount moves Darrick J. Wong
2026-03-13 19:39 ` Zorro Lang
2026-03-10 3:53 ` [PATCH 12/14] xfs: test xfs_healer wont repair the wrong filesystem Darrick J. Wong
2026-03-13 19:53 ` Zorro Lang
2026-03-10 3:53 ` [PATCH 13/14] xfs: test xfs_healer background service Darrick J. Wong
2026-03-13 19:56 ` Zorro Lang
2026-03-10 3:53 ` [PATCH 14/14] xfs: test xfs_healer startup service Darrick J. Wong
2026-03-13 19:58 ` Zorro Lang
2026-03-12 14:21 ` [PATCH 15/14] xfs: test xfs_healer can follow private mntns mount moves Darrick J. Wong
2026-03-13 20:05 ` Zorro Lang
2026-03-13 23:41 ` Darrick J. Wong
-- strict thread matches above, loose matches on Subject: below --
2026-03-03 0:33 [PATCHSET v8 1/2] fstests: test generic file IO error reporting Darrick J. Wong
2026-03-03 0:40 ` [PATCH 1/1] generic: test fsnotify filesystem " Darrick J. Wong
2026-03-03 9:21 ` Amir Goldstein
2026-03-03 14:51 ` Christoph Hellwig
2026-03-03 14:56 ` Amir Goldstein
2026-03-04 10:10 ` Jan Kara
2026-03-03 14:54 ` Christoph Hellwig
2026-03-03 16:06 ` Gabriel Krisman Bertazi
2026-03-03 16:12 ` Christoph Hellwig
2026-03-03 16:38 ` Darrick J. Wong
2026-03-03 16:49 ` Darrick J. Wong
2026-03-03 16:53 ` Christoph Hellwig
2026-03-03 17:59 ` 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=20260316221658.GO6069@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=amir73il@gmail.com \
--cc=fstests@vger.kernel.org \
--cc=gabriel@krisman.be \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=zlang@redhat.com \
/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