Date: Wed, 10 Aug 2022 16:26:28 -0400 From: "David E. Cross" <david@crossfamilyweb.com> To: Kyle Evans <kevans@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: "missing" SAs/ENs? Message-ID: <cffa2b9d-8cdc-6695-ada4-c56dabe87685@crossfamilyweb.com> In-Reply-To: <CACNAnaFAG3A0HPPSYb1TVBvSAG1D4McHoQVJQb0qH2bD5sc-pw@mail.gmail.com> References: <84c585bb-15d8-75e9-0a9c-3f10e94314ef@crossfamilyweb.com> <CACNAnaFAG3A0HPPSYb1TVBvSAG1D4McHoQVJQb0qH2bD5sc-pw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/10/22 16:14, Kyle Evans wrote: > On Wed, Aug 10, 2022 at 12:36 PM David E. Cross > <david@crossfamilyweb.com> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cffa2b9d-8cdc-6695-ada4-c56dabe87685>