Re: git: 43741377b143 - main - security/openssl: Security update to 1.1.1n

On 2022-Mar-19, at 12:54, Mark Johnston <markj@FreeBSD.org> wrote:

> On Sat, Mar 19, 2022 at 12:00:20PM -0700, Mark Millard wrote:
>> On 2022-Mar-19, at 11:07, Thomas Zander <riggs@freebsd.org> wrote:
>> 
>>> On Sat, 19 Mar 2022 at 18:32, Mark Millard <marklmi@yahoo.com> wrote:
>>>> May be report to Mark J. how to run the same test builds
>>>> that failed for -p8 but worked for -p7?
>>> 
>>> Sure, good point.
>>> A build that reliably causes broken packages on p8 but not on p7 for
>>> me is running:
>>> 
>>> poudriere testport -o multimedia/mplayer -j <13.0-amd64-jail here>
>>> 
>>> This caused the broken png and python packages when they were built as
>>> dependencies.
>>> In poudriere.conf I set this:
>>> DISTFILES_CACHE=/vcache/distfiles
>>> CCACHE_DIR=/vcache/ccache
>>> ALLOW_MAKE_JOBS=yes
>>> 
>>> The ALLOW_MAKE_JOBS should increase the number of parallel IO
>>> operations in-flight on the pool, maybe this increases the likelihood
>>> of triggering the issue?
>>> The DISTFILES_CACHE and CCACHE_DIR are in the same zfs pool as
>>> /poudriere, not sure if this is relevant.
>>> The zfs pool is a single disk, no raid, mirror or anything fancy.
>> 
>> On a ThreadRipper 1950X, PCIe Optane storage, 128 GiBytes of
>> RAM, I've used bectl to boot the 13.0_RELEASE-p8 environment
>> and have started:
>> 
>> poudriere testport -o multimedia/mplayer -j13_0R-amd64-bulk_a
>> 
>> where the jail had nothing built in it at the start. So:
>> 
>> [00:00:08] Building 271 packages using up to 32 builders
>> 
>> The primary difference is that I've never used ccache and
>> did not try to do so here. The "zfs pool is a single disk,
>> no raid, mirror or anything fancy" is accurate, as is the
>> use of ALLOW_MAKE_JOBS= .
>> 
>> That did not take long . . .
>> 
>> It proves that ccache is not required. Also some files
>> seem to get only small blocks of zero-bytes, others
>> large ones. But I've not checked for the null characters
>> being at the end instead of earlier in the file.
> 
> I still am not able to reproduce it.  I think it's indeed a concurrency
> problem, and I found a possible culprit.  Mark or Thomas, if you're able
> to build a new kernel from the releng/13.0 branch and test it, could you
> please try this patch?
> 

Sure. (I build ports in a way that allows large load
averages relative to the hardware-thread count. I also
have a lot of swap configured. I avoid significant use
of tmpfs.)

> diff --git a/sys/contrib/openzfs/module/zfs/dnode.c b/sys/contrib/openzfs/module/zfs/dnode.c
> index 8592c5f8c3a9..b69ba68ec780 100644
> --- a/sys/contrib/openzfs/module/zfs/dnode.c
> +++ b/sys/contrib/openzfs/module/zfs/dnode.c
> @@ -1661,7 +1661,7 @@ dnode_is_dirty(dnode_t *dn)
> 	mutex_enter(&dn->dn_mtx);
> 
> 	for (int i = 0; i < TXG_SIZE; i++) {
> -		if (list_head(&dn->dn_dirty_records[i]) != NULL) {
> +		if (multilist_link_active(&dn->dn_dirty_link[i])) {
> 			mutex_exit(&dn->dn_mtx);
> 			return (B_TRUE);
> 		}
> 

Change made.
Rebuilt.
Reinstalled.
Rebooted into the 13_0R-amd64 be area.
Bulk build started.
Bulk build completed.
(Took longer because I let it run to completion.)

No explicit reports of null characters. The same 2 ports that
failed before, not reporting zero-byte issues, failed again.
Likely independent issues:

[00:28:28] Failed ports: security/libgcrypt:build print/freetype2:package

Overall it skipped something like 54 ports.

libgcrypt-1.9.4.log . . .

--- basic.o ---
basic.c:315:16: error: inline assembly requires more registers than available
  asm volatile("movdqu %[data0], %%xmm0\n"
               ^
basic.c:315:16: error: inline assembly requires more registers than available
basic.c:315:16: error: inline assembly requires more registers than available
basic.c:315:16: error: inline assembly requires more registers than available
basic.c:315:16: error: inline assembly requires more registers than available
basic.c:315:16: error: inline assembly requires more registers than available
basic.c:315:16: error: inline assembly requires more registers than available
basic.c:315:16: error: inline assembly requires more registers than available
basic.c:315:16: error: inline assembly requires more registers than available
basic.c:315:16: error: inline assembly requires more registers than available
basic.c:315:16: error: inline assembly requires more registers than available
basic.c:315:16: error: inline assembly requires more registers than available
--- mpitests ---
. . .
--- basic.o ---
basic.c:315:16: error: inline assembly requires more registers than available
basic.c:315:16: error: inline assembly requires more registers than available
basic.c:315:16: error: inline assembly requires more registers than available
basic.c:315:16: error: inline assembly requires more registers than available
basic.c:315:16: error: inline assembly requires more registers than available
basic.c:315:16: error: inline assembly requires more registers than available
basic.c:315:16: error: inline assembly requires more registers than available
fatal error: too many errors emitted, stopping now [-ferror-limit=]


freetype2-2.11.1.log . . .

===>  Building package for freetype2-2.11.1
pkg-static: Unable to access file /wrkdirs/usr/ports/print/freetype2/work/stage/usr/local/lib/libfreetype.so:No such file or directory
pkg-static: Unable to access file /wrkdirs/usr/ports/print/freetype2/work/stage/usr/local/lib/libfreetype.so.6:No such file or directory
pkg-static: Unable to access file /wrkdirs/usr/ports/print/freetype2/work/stage/usr/local/lib/libfreetype.so.6.18.1:No such file or directory
*** Error code 1


I think this indicates that your fix works.



For reference:

# ~/fbsd-based-on-what-commit.sh -C /usr/ports/
branch: main
merge-base: 0c4fe38bd1b9e3ede128751db17a8a2d1bdffe6f
merge-base: CommitDate: 2022-03-15 16:15:33 +0000
0c4fe38bd1b9 (HEAD -> main, freebsd/main, freebsd/HEAD) misc/urh: Update 2.9.2 -> 2.9.3
n577366 (--first-parent --count for merge-base)



===
Mark Millard
marklmi at yahoo.com