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 10:13, Mike Karels <mike@karels.net> wrote:

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

My understanding is that powerpc64le does not in FreeBSD:
there is no powerpcle in FreeBSD. So, not even chroot style
support for 32-bit little endian use.

If I understand right, no 32 bit little endian ABI is defined,
other than the void linux activity's material, anyway.

It may be that all big endian POWER use has lib32 support, but
I'm not sure if all POWER has big endian FreeBSD support. May
be POWER9 (10?) still has such support in FreeBSD.

===
Mark Millard
marklmi at yahoo.com