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 07:36, Mark Millard <marklmi@yahoo.com> wrote:

> 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

I forgot to mention an important step: before chroot is
used, I preload various kernel modules that are used in
the Kyuafile tests --because the chroot'd activity will
not cause the loads of themsleves but will use the
modules if they have already been loaded.

> 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