public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
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
> > 
> 

  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