Re: Looks like the kyua zfs tests likely are not used on aarch64 or other contexts with unsigned char

On Sep 10, 2023, at 11:21, Warner Losh <imp@bsdimp.com> wrote:

> On Sun, Sep 10, 2023, 11:10 AM Mark Millard <marklmi@yahoo.com> wrote:
>> On Sep 10, 2023, at 00:31, Mark Millard <marklmi@yahoo.com> wrote:
>> 
>> > kyua tests that use the:
>> > 
>> > /usr/tests/sys/cddl/zfs/bin/mkfile
>> > 
>> > program like so (for example):
>> > 
>> > mkfile 500M /testpool.1861/bigfile.0
>> > 
>> > (which should be valid) end up with mkfile
>> > instead reporting:
>> > 
>> > Standard error:
>> > Usage: mkfile [-nv] <size>[e|p|t|g|m|k|b] <filename> ...
>> > 
>> > which prevent the kyua test involved from working.
>> > 
>> > Turns out this is from expecting char to be always
>> > signed (so a -1 vs. 255 distinction, here in an
>> > aarch64 context):
>> > 
>> > . . .
>> > (gdb) list
>> > 179 /* Options. */
>> > 180 while ((ch = getopt(argc, argv, "nv")) != -1) {
>> > 181 switch (ch) {
>> > 182 case 'n':
>> > 183 nofill = 1;
>> > 184 break;
>> > 185 case 'v':
>> > (gdb) print ch
>> > $16 = 255 '\377'
>> > (gdb) print/x -1
>> > $17 = 0xffffffff
>> > (gdb) print/x ch
>> > $18 = 0xff
>> > . . .
>> > 
>> > With the mix of unsigned and signed it ends up
>> > being a 0xffu != 0xffffffffu test, which is
>> > always true.
>> > 
>> > So the switch is reached as if a "-" prefix was
>> > present (that is not). Then the "option" is classified
>> > as invalid and the usage message is produced.
>> > 
>> > Apparently no one had noticed. That, in turn, suggests a
>> > lack of inspected testing on aarch64, powerpc64,
>> > powerpc64le, armv7, powerpc, and powerpcspe. That, in
>> > turn, suggests that kyua test inspection for the likes
>> > of aarch64 is not historically a part of the release
>> > process for openzfs or for operating systems that include
>> > openzfs.
>> > 
>> 
>> Looks like the mkfile.c traces back to a former port
>> sysutils/mkfile that was unfetchable as of 2019. And,
>> looking around, it seems the kyua zfs tests may be a
>> FreeBSD only thing, not adopted in openzfs.
>> 
>> So various implicit assumptions when I wrote the note
>> do not actually hold.
>> 
>> FreeBSD would have to do additional testing via kyua,
>> beyond what openzfs does for testing, to discover the
>> unsigned char related mis-behavior in the mkfile that
>> FreeBSD's kyua tests use. Only FreeBSD variants are
>> likely to have a similar status, not general openzfs
>> including operating systems.
> 
> I wonder how hard ot would be to look for the char = getopt() pattern with coccinelle
> 

Unsure.

But to be sure that the implication that I was also trying
to point out is not lost: kyua testing of zfs (and more?)
for aarch64 (tier 1) is apparently not being done (or at
least the results are not being inspected). Similarly for
armv7 and all the powerpc*'s (not tier 1's, however, so
not as surprising).


Side note:

Via other exchanges that have been going on I learned to
look in the likes of:

https://ci.freebsd.org/job/FreeBSD-main-amd64-testvm/*/consoleText

for what to "pkg install" for kyua test runs to use for
normal runs (at least the subset compatible with
architecture being tested). I'd only figured out a (large)
subset previously for aarch64 and armv7.

I'm not aware of there being other documentation for what
is appropriate for setting up such for kyua runs.

===
Mark Millard
marklmi at yahoo.com