Date: Sat, 19 Mar 2022 16:13:27 +0100 From: Matthias Fechner <mfechner@FreeBSD.org> To: Mark Johnston <markj@freebsd.org>, Thomas Zander <riggs@freebsd.org> Cc: Rene Ladan <rene@freebsd.org>, Christoph Moench-Tegeder <cmt@burggraben.net>, Bernard Spil <brnrd@freebsd.org>, "ports-committers@FreeBSD.org" <ports-committers@freebsd.org>, dev-commits-ports-all@freebsd.org, dev-commits-ports-main@freebsd.org, secteam@freebsd.org Subject: Re: git: 43741377b143 - main - security/openssl: Security update to 1.1.1n Message-ID: <b15fb32d-b891-2625-c443-0ac6f13902e0@FreeBSD.org> In-Reply-To: <YjXiyoRt7FgMp47b@framework> References: <b3b4e822-bc87-357f-8e15-3492526c5a9c@FreeBSD.org> <CAFU734wn1kqoQfpuxT%2BSQdZ--VFKawhHwwFimj6Z8RyzLD-bfQ@mail.gmail.com> <YjTV6f5B8IAUFoWm@elch.exwg.net> <YjTb28jXMkJplc8s@elch.exwg.net> <CAFU734zacFy_%2BDvwG6W55X1=Yu8FYLvTV6DbyhW1azkUwXzG3Q@mail.gmail.com> <YjTrVsQi0ZTdadQK@elch.exwg.net> <579f562b-8add-d3f7-77c9-1a6126bd282b@FreeBSD.org> <CAFU734w5ycC1aY4x1Qoy3SL0Og=8osq%2BhG-mBvaLFrLYHm-MOw@mail.gmail.com> <YjW6ZCkdIMq/lXGA@freefall.freebsd.org> <CAFU734zX9DJSsFv=46=6GdVdzxk%2B0yZz-brALdLcdY0m8BQ6Dg@mail.gmail.com> <YjXiyoRt7FgMp47b@framework>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------h94aaHn1qPCMv9K4KkRNSE1P Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Am 19.03.2022 um 15:03 schrieb Mark Johnston: >> 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@ 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. > Looking at it now. Does the problem appear on systems updated with > freebsd-update, or built from source, or both? I use only freebsd-update. Gruß Matthias -- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook --------------h94aaHn1qPCMv9K4KkRNSE1P Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">Am 19.03.2022 um 15:03 schrieb Mark Johnston:<br> </div> <blockquote type="cite" cite="mid:YjXiyoRt7FgMp47b@framework"> <blockquote type="cite" style="color: #007cff;"> <pre class="moz-quote-pre" wrap="">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@ 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. </pre> </blockquote> <pre class="moz-quote-pre" wrap="">Looking at it now. Does the problem appear on systems updated with freebsd-update, or built from source, or both? </pre> </blockquote> <p>I use only freebsd-update.<br> </p> <pre class="moz-signature" cols="72"> Gruß Matthias -- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook </pre> </body> </html> --------------h94aaHn1qPCMv9K4KkRNSE1P--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b15fb32d-b891-2625-c443-0ac6f13902e0>