From nobody Sun Sep 10 18:21:16 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RkJ8C1yH1z4sGD7 for ; Sun, 10 Sep 2023 18:21:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RkJ8B4Tq9z4fV5 for ; Sun, 10 Sep 2023 18:21:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-9a65f9147ccso465022766b.1 for ; Sun, 10 Sep 2023 11:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1694370088; x=1694974888; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=abD7goBSEuLS/Xh94ZiyPK937DJ64isvmy2QjqmoqzE=; b=RzWaEAndVIAYQtttdx9gLKeGw49er7Ig/IDk18vUaLN/gCBfTbNZWsJvkC40ZAxk9B tAVU4AwSrCw3qhdcrxvAyWQlnuiVOjewGlmqC6Z67aD7v/Q4A7cMqGx2OgKdzYazH+UG H+irUmAG4hjxCdEd2F+KPqVn0Z1TqkGtx4mbgGUT997ubmTyQJbm5ufFpkKOkl/uRJa3 3RJHevkYyxD+68FIP4z5zibh0svQB/3MySsbgNVzlX/973h0NB+dHvv0kwTPEOO9Qe6y ams0DIvc+9YkOSkSgZn5JaokjB4Zx9SzbVlf6XtjnW9MVFey+T7Jw5MC9X/y+/39Oeoq nOxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694370088; x=1694974888; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=abD7goBSEuLS/Xh94ZiyPK937DJ64isvmy2QjqmoqzE=; b=KQebVxH2gyDdj/ZtmO7oukKxEPRU0N3dM410N3C5izMt+C/DSLOpVD1iBBKb7JUf5o u/mMrfSjoAgbgfzOA37/QVDFzeH14mLtqLCEaPHRMAYgRfk3fczAjscNbAs/of5Q6n05 WkUOtj9D5DRvUmwiO8HNjE5512COiQgwVdLWCTLeXkanGE0ytg/WhIW32JPGffsA81hY yxbGvW2G2jpf0l8wcw9YKoTnfD299j6ql8RvzHSW0qpUhR6EgIY4zhAZMuIvhz5tLEIX S9LPmpZkqQ2R+mZqW2Q+TUCR0QITElPYBAA152oXZqdRQuQ1jmvcTlyQ/LCmWSyLAdt6 ySiw== X-Gm-Message-State: AOJu0YxrBuPlH1HYf/T92nhTIg8TWIf6vdpZhOgDguHmihsTiuRiN0L1 cnm8dwGiDmaQ4HRTREJLpyVi+o3gTi62tValKIMLeg== X-Google-Smtp-Source: AGHT+IGO+g+ru/dUmvjmlrKU5ZyNWNccw02kNd6p/f722m/5gR/oMy7qBF4vBvZb0DsmsykODS/iffxjKGqOBOB3pLA= X-Received: by 2002:a17:906:5398:b0:9a1:a916:17c0 with SMTP id g24-20020a170906539800b009a1a91617c0mr6773474ejo.50.1694370088304; Sun, 10 Sep 2023 11:21:28 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <96C2F8F3-D3F0-48FC-BEEC-E3C983BD680A@yahoo.com> In-Reply-To: From: Warner Losh Date: Sun, 10 Sep 2023 12:21:16 -0600 Message-ID: Subject: Re: Looks like the kyua zfs tests likely are not used on aarch64 or other contexts with unsigned char To: Mark Millard Cc: Martin Matuska , Alexander Motin , Pawel Jakub Dawidek , Glen Barber , Mike Karels , Current FreeBSD , FreeBSD-STABLE Mailing List , freebsd-arm Content-Type: multipart/alternative; boundary="0000000000003b54c306050547d8" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4RkJ8B4Tq9z4fV5 --0000000000003b54c306050547d8 Content-Type: text/plain; charset="UTF-8" On Sun, Sep 10, 2023, 11:10 AM Mark Millard wrote: > On Sep 10, 2023, at 00:31, Mark Millard 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] [e|p|t|g|m|k|b] ... > > > > 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 Warner === > Mark Millard > marklmi at yahoo.com > > > --0000000000003b54c306050547d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Sep 10, 2023, 11:10 AM Mark Millard <marklmi@yahoo.com> wrote:
On Sep 10, 2023, at 00:31, Mark Millard <mar= klmi@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 =3D getopt(argc, argv, "nv")) !=3D -1) {
> 181 switch (ch) {
> 182 case 'n':
> 183 nofill =3D 1;
> 184 break;
> 185 case 'v':
> (gdb) print ch
> $16 =3D 255 '\377'
> (gdb) print/x -1
> $17 =3D 0xffffffff
> (gdb) print/x ch
> $18 =3D 0xff
> . . .
>
> With the mix of unsigned and signed it ends up
> being a 0xffu !=3D 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 c= har =3D getopt() pattern with coccinelle

<= div dir=3D"auto">Warner

=
=3D=3D=3D
Mark Millard
marklmi at yahoo.com


--0000000000003b54c306050547d8--