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
