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

> From: Mark Johnston <markj_at_freebsd.org> 
> Date: Sat, 19 Mar 2022 12:42:59 -0400
> On Sat, Mar 19, 2022 at 12:40:45PM +0100, Thomas Zander wrote:
> > On Sat, 19 Mar 2022 at 12:11, Rene Ladan <rene_at_freebsd.org> wrote:
> > >
> > > On Sat, Mar 19, 2022 at 11:04:58AM +0100, Thomas Zander wrote:
> > > > On Sat, 19 Mar 2022 at 09:00, Matthias Fechner <mfechner_at_freebsd.org> wrote:
> > > >
> > > > > I can confirm now, the problem is definitely related to the -p8 update.
> > > > > I rolled back now to -p7 using `freebsd-update rollback`.
> > > > > [...]
> > > > > System is now up and running again.
> > > > > This all works even if poudriere jail is using -p8. No need to downgrade the jail/base version poudriere is using.
> > > > > It is caused by the kernel so the ZFS patch seems to be broken and -p8 should maybe not rolled out to not break more systems of users.
> > > >
> > > > On top of "stop rollout", there is the question how to identify the
> > > > broken files for the users who have already upgraded to -p8. A `zpool
> > > > scrub` presumably won't help.
> > >
> > > I think it also applies to 13.1-BETA2 ?
> > >
> > > Should we involve/CC some src committers?
> > 
> > I have just rolled back to -p7 and run a number of test builds in
> > poudriere (the jails still have the -p8 user land). I see the same as
> > Matthias and Christoph, the rollback to the -p7 kernel/zfs resolved
> > the build problems, there are no NUL byte files generated anymore.
> > Adding markj_at_ to the discussion. Mark, the TLDR so far:
> > - One of the zfs patches in -p8 seems to cause erroneous writes.
> > - We noticed because of many build failures with poudriere (presumably
> > highly io-loaded during build).
> > - Symptom: Production of files with large runs of NUL-bytes.
> 
> I've had zero luck reproducing this locally.  I built several hundred
> ports, including textproc/py-pystemmer mentioned elsewhere in the
> thread, without any failures or instances of zero-filled files.  Another
> member of secteam also hasn't been able to trigger any build failures on
> -p8.  Any hints on a reproducer would be useful.
> 
> We can simply push a -p9 which reverts EN-22:10 and :11, but of course
> it would be preferable to precisely identify the problem.

Anything about the types of hardware involved that is
different for those getting the problem vs. those that
do not get the problem? May be it would be appropriate
for folks getting the problem to detail their hardware
configurations, including storage hardware.

===
Mark Millard
marklmi at yahoo.com