Date: Sat, 19 Mar 2022 15:54:04 -0400 From: Mark Johnston <markj@freebsd.org> To: Mark Millard <marklmi@yahoo.com> Cc: Thomas Zander <riggs@freebsd.org>, freebsd-ports@freebsd.org, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: git: 43741377b143 - main - security/openssl: Security update to 1.1.1n Message-ID: <YjY03OHBQlSDqh94@framework> In-Reply-To: <DFE73A51-BABA-4138-93CA-60245C16EA86@yahoo.com> References: <2E632408-4D4E-426C-8DC7-A1024A1D328D.ref@yahoo.com> <2E632408-4D4E-426C-8DC7-A1024A1D328D@yahoo.com> <CAFU734xvJB3a=0TE=bQvjp7wN=8iKP1AbuEqrP1MF8vOp1fb7Q@mail.gmail.com> <DFE73A51-BABA-4138-93CA-60245C16EA86@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
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);
}
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YjY03OHBQlSDqh94>