Re: Error in generic/397 test script?

[Eric Biggers <ebiggers@kernel.org>]

On Mon, Jan 20, 2025 at 12:32:28PM +0000, David Howells wrote:
> Hi Eric,
> 
> In the generic/397 test script, you placed:
> 
> 	$XFS_IO_PROG -f $SCRATCH_MNT/edir/newfile |& _filter_scratch
> 	$XFS_IO_PROG -f $SCRATCH_MNT/edir/0123456789abcdef |& _filter_scratch
> 
> but neither of those lines actually has a command on it, and when I run it,
> I'm seeing xfs_io hang just waiting endlessly for someone to type commands on
> stdin.
> 
> Would it be better to do:
> 
> 	echo >$SCRATCH_MNT/edir/newfile |& _filter_scratch
> 	echo >$SCRATCH_MNT/edir/0123456789abcdef |& _filter_scratch

Those commands try to create new files and are supposed to fail with ENOKEY
because the directory's encryption key is not present, as is explained in the
comment just above them and can also be seen from 397.out.

First, I'm guessing the context here is that you're testing some (not yet
upstream) kernel patches that introduce a bug where creating these files does
not in fact fail?  That bug will need to be fixed before your patches are
merged, of course.

Second, yes it would be a good idea to replace these with something that don't
hang in the case of a kernel bug that allows the creation of these files.  This
could be done using a shell redirection as you've proposed, but it would have to
go in a subshell for the stderr to be filtered by _filter_scratch.  Feel free to
send a patch after you've fixed that and tested it with upstream.

- Eric