Re: For snapshot builds: armv7 chroot on aarch64 has kyua test -k /usr/tests/Kyuafile sys/kern/kern_copyin hung up [in getpid?], unkillable, prevents reboot

On Jul 7, 2023, at 06:50, Mike Karels <mike@karels.net> wrote:

> On 7 Jul 2023, at 6:06, John F Carr wrote:
> 
>> On Jul 6, 2023, at 20:42, Mike Karels <mike@karels.net> wrote:
>>> 
>>> 
>>> Thanks for isolating this.  Let me know when you have the bug number.
>>> I just tested a fix (the compat code drops the reference on the current
>>> address space an extra time, probably freeing it).
>>> 
>>> Mike
> 
> The fix is in https://cgit.freebsd.org/src/commit/?id=be30fd3ab2e8418a696e69f54a91a7e2db5962de.
> 
>> The bug was introduced in January, 2022.   It allows 32 bit binaries to crash a 64 bit system when COMPAT_FREEBSD32 is on.  Test coverage of the buggy function (sysctl_kern_proc_vm_layout) was added at the same time.
>> 
>> There should be routine runs of 32 bit test suites on 64 bit systems.  Although i386 and armv7 are tier 2 systems, the tier 1 COMPAT_FREEBSD32 kernel code needs to be exercised.  This bug was only discovered by manually running tests in the right environment, 17 months after automated testing could have discovered it.
> 
> That is not so simple currently, as the shared libraries for the
> test environment are not part of 32-bit compatibility package.
> The required bits could be extracted from the corresponding 32-bit
> build, but that isn't easy to automate.  Fortunately, I think that
> very few of the tests exercise any 32-bit-specific code paths.

One way that I demonstrated this problem on an aarch64 system
that supports aarch32/armv7 in user space was via the use of
an official snapshot armv7 image. In my case I:

A) dd'd the image to USB3 media (after downloading it)
B) mounted the ufs file system on the media to a mount point
C) used a chroot into that mount point to run the:
    "kyua test -k /usr/tests/Kyuafile"

(I happened to do all that as root.)

There may be viable alternatives to dd'ing to allow an analogy to
(B) for (C) to use. I've not experimented with using a jail
instead of a chroot.

One can also install an armv7 world into a local directory tree
and then use chroot (or analogous).

How far off is an analogous sort of procedure from being reasonable
to automate?

i386, of course, also has lib32 and independently testing that is
a messier issue, including trying to use /usr/tests/Kyuafile based
testing that avoids use of chroot (or analogous). I'm not claiming
lib32 has as simple of a potential path to automated testing.

I do not know if FreeBSD has powerpc64 hardware able to use a
powerpc world directory tree analogously. Such hardware may be too
old and otherwise problematical, making it not viable to automate
testing.

===
Mark Millard
marklmi at yahoo.com