From nobody Fri Jul 07 17:13:51 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QyKkB0zKlz4m7s3; Fri, 7 Jul 2023 17:13:54 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QyKk95BT5z4XcR; Fri, 7 Jul 2023 17:13:53 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 367HDqEX027605; Fri, 7 Jul 2023 12:13:52 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1688750032; bh=kx053mV3FBG//JaNV4/4mO1057tENhF0eSSB79TGF38=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=qE2Yr5GrHJJb0twrzsAvoxTGNci2gyqjQ786CAS6JZPNq+O3XBF98LkYzWeSvwhay MmeV0YY2va1IldiADuaCH5jMnKB5STRqX/fT3MXyZpuuL9HB052odw30DLHBk973Wo 7mCibd5s1owZ4I+qHIB1e6kXVPKV0h+QMuTEivRGdrOS0V+eWxUxCwJ6N+axdFwq/p J/hk67HodecDobRsJwa56gxKo886K8pMUMgu0KVU7KZKDLkk/n429g60CPbFKJNdtj +WiCThGh/PdSnTZjv4r3PeM+SEDXJXQBxTg+M7zGZzXvKDgDbbABwGJhS6s/NZ+akP 8/9AwC+wfF4ig== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id gDDUBNBHqGTTawAAs/W3XQ (envelope-from ); Fri, 07 Jul 2023 12:13:52 -0500 From: Mike Karels To: Mark Millard Cc: John F Carr , Current FreeBSD , freebsd-arm Subject: 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 Date: Fri, 07 Jul 2023 12:13:51 -0500 X-Mailer: MailMate (1.14r5964) Message-ID: <71C767A0-AE59-4A6C-A210-27386C80F26F@karels.net> In-Reply-To: <3B31195E-9CAB-4F79-90D9-9E05927235C8@yahoo.com> References: <7A41DED4-876F-4270-A980-549A4832B39A.ref@yahoo.com> <7A41DED4-876F-4270-A980-549A4832B39A@yahoo.com> <3404EA26-BFDD-4B87-830B-62CB6E91C0BD@karels.net> <240A32EC-E255-4B04-83B3-0D57308B701B@mit.edu> <106875C8-76F9-4307-A495-D41EAE8F1C8B@karels.net> <9EE9CFF2-378B-42D0-A171-9481286805C2@yahoo.com> <3B31195E-9CAB-4F79-90D9-9E05927235C8@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4QyKk95BT5z4XcR X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 7 Jul 2023, at 11:38, Mark Millard wrote: > On Jul 7, 2023, at 07:36, Mark Millard wrote: > >> On Jul 7, 2023, at 06:50, Mike Karels wrote: >> >>> On 7 Jul 2023, at 6:06, John F Carr wrote: >>> >>>> On Jul 6, 2023, at 20:42, Mike Karels wrote: >>>>> >>>>> >>>>> Thanks for isolating this. Let me know when you have the bug numbe= r. >>>>> I just tested a fix (the compat code drops the reference on the cur= rent >>>>> address space an extra time, probably freeing it). >>>>> >>>>> Mike >>> >>> The fix is in https://cgit.freebsd.org/src/commit/?id=3Dbe30fd3ab2e84= 18a696e69f54a91a7e2db5962de. >>> >>>> 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 tim= e. >>>> >>>> There should be routine runs of 32 bit test suites on 64 bit systems= =2E Although i386 and armv7 are tier 2 systems, the tier 1 COMPAT_FREEBS= D32 kernel code needs to be exercised. This bug was only discovered by m= anually 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