On 7 Jul 2023, at 11:38, Mark Millard wrote: > On Jul 7, 2023, at 07:36, Mark Millard <mark...@yahoo.com> wrote: > >> On Jul 7, 2023, at 06:50, Mike Karels <m...@karels.net> wrote: >> >>> On 7 Jul 2023, at 6:06, John F Carr wrote: >>> >>>> On Jul 6, 2023, at 20:42, Mike Karels <m...@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