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 7 Jul 2023, at 11:38, Mark Millard wrote:

> 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?

It would be easier to use the packages rather than the full image
(base.txz and tests.txz).  But doing this as part of a CI setup would
mean fetching things from a different source from the install image,
and then of course doing various configuration.  It's always a Small
Matter of Programming.  Doing a full chroot gets into some other
problems, e.g. mdconfig doesn't currently work in compatibility
mode.  It doesn't seem that automating all this would yield much;
it's hard enough to do manually.

>> 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 think the problem is essentially the same.  A chroot could be used
or a 32-bit library setup (which would test the libraries as well).

>> 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.

Powerpc supports 32-bit libraries, unlike arm (so far).

		Mike