From nobody Wed Aug 10 20:26:28 2022 X-Original-To: freebsd-hackers@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 4M31gJ0Yw0z4YCtS for ; Wed, 10 Aug 2022 20:26:36 +0000 (UTC) (envelope-from david@crossfamilyweb.com) Received: from mail.dcrosstech.com (rrcs-24-97-5-250.nys.biz.rr.com [24.97.5.250]) (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 (4096 bits) client-digest SHA256) (Client CN "mail.dcrosstech.com", Issuer "DCrossTech.com LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M31gH075sz3vJD; Wed, 10 Aug 2022 20:26:34 +0000 (UTC) (envelope-from david@crossfamilyweb.com) X-Virus-Scanned: amavisd-new at dcrosstech.com Received: from [10.1.7.155] (d155.p9.wifi.dcrosstech.com [10.1.7.155]) (authenticated bits=0) by mail.dcrosstech.com (8.15.2/8.15.2) with ESMTPSA id 27AKQSRW022017 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 10 Aug 2022 20:26:29 GMT (envelope-from david@crossfamilyweb.com) X-Authentication-Warning: mail.priv.dcrosstech.com: Host d155.p9.wifi.dcrosstech.com [10.1.7.155] claimed to be [10.1.7.155] Message-ID: Date: Wed, 10 Aug 2022 16:26:28 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: "missing" SAs/ENs? Content-Language: en-US To: Kyle Evans Cc: freebsd-hackers@freebsd.org References: <84c585bb-15d8-75e9-0a9c-3f10e94314ef@crossfamilyweb.com> From: "David E. Cross" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4M31gH075sz3vJD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@crossfamilyweb.com designates 24.97.5.250 as permitted sender) smtp.mailfrom=david@crossfamilyweb.com X-Spamd-Result: default: False [-2.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:11351, ipnet:24.97.0.0/16, country:US]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[crossfamilyweb.com]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[david]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_XAW(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 8/10/22 16:14, Kyle Evans wrote: > On Wed, Aug 10, 2022 at 12:36 PM David E. Cross > wrote: >> We just had a big dump of multiple SAs and ENs yesterday. At least one >> of those I know has been pending for months (and AFAIK was ready to go >> technically within days). Additionally I know of and personally have >> been hit by 3 other things that I feel really should have been ENs and >> out by now (and am maintaining my own patches for): >> >> 1. loader handling of root geli disks is broken. >> >> This one is a big deal, it completely bricks systems, there has >> been a patch for months. >> >> 2. userboot.so doesn't work when compiled with BIND_NOW. relatively >> minor, affects few people with non-standard build options, but likewise >> known for a long time, patch committed. >> >> 3. compile hang in certain circumstances with LLVM with CPU targeting on >> AVX512 processors. Again, minor, affects few people with non-standard >> build options, but also know for a long time with a patch >> >> >> I suspect by the fact that I've personally hit these 3 that there exist >> many others that other people have hit that I have not (yet. >> >> >> It feels like there is a backup or stoppage of EN/SA processing. >> > I'm not familiar with #1/#3, but I didn't feel that #2 warranted an EN > and thus, didn't fill out a template for it. This is a non-standard > build configuration and has been broken for a long enough time that > there's almost certainly nobody else trying this at all, given that > yours was the first report. Errata notices are only issued on an > as-needed basis, when someone fills out the template and submits it. > > Thanks, > > Kyle Evans #2 wasn't even me who reported it, I (mercifully) found all of these issues by searching existing bug reports (which also shows this is hitting multiple people, some of us just may squeak louder than others).  Also why I didn't file an EN request, I thought it was handled. I definitely appreciate that non-standard compile or execution options can complicate decisions on what all to include as an EN; these (to me) seem to fit that.  They are a result of configuring the system in a way that is documented to work, are hard breaks (removing functionality) when it doesn't work, and the patches for all are trivial (no more than a few lines).  For example if 'device foobar' prevented the kernel from compiling, or caused a panic, even if 'foobar' was not in GENERIC, I'd expect an EN to be issued.  if it just worked poorly, maybe not, especially if it was dozens of lines. Where is the EN template?  I'll gladly fill out 3 for these.