On Fri, Jun 6, 2025 at 11:17 AM Jiri Slaby <[email protected]> wrote: > > On 05. 06. 25, 19:31, Uros Bizjak wrote: > > On Thu, Jun 5, 2025 at 7:15 PM Dave Hansen <[email protected]> wrote: > >> > >> On 6/5/25 07:27, Jiri Slaby wrote: > >>> Reverting this gives me back to normal sizes. > >>> > >>> Any ideas? > >> > >> I don't see any reason not to revert it. The benefits weren't exactly > >> clear from the changelogs or cover letter. Enabling "various compiler > >> checks" doesn't exactly scream that this is critical to end users in > >> some way. > >> > >> The only question is if we revert just this last patch or the whole series. > >> > >> Uros, is there an alternative to reverting? > > > > This functionality can easily be disabled in include/linux/compiler.h > > by not defining USE_TYPEOF_UNQUAL: > > > > #if CC_HAS_TYPEOF_UNQUAL && !defined(__CHECKER__) > > # define USE_TYPEOF_UNQUAL 1 > > #endif > > > > (support for typeof_unqual keyword is required to handle __seg_gs > > qualifiers), but ... > > > > ... the issue is reportedly fixed, please see [1], and ... > > Confirmed, I need a patched userspace (libbpf). > > > ... you will disable much sought of feature, just ask tglx (and please > > read his rant at [2]): > > Given this is the second time I hit a bug with this, perhaps introduce > an EXPERIMENTAL CONFIG option, so that random users can simply disable > it if an issue occurs? Without the need of patching random userspace and > changing random kernel headers?
In both cases, the patch *exposed* a bug in a related utility software, it is not that the patch itself is buggy. IMO, waving off the issue by disabling the feature you just risk the bug in the related software to hit even harder in some not too distant future. Uros.
