| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <878qoczbhn.fsf@intel.com> Date: Mon, 07 Apr 2025 10:17:40 +0300 From: Jani Nikula <jani.nikula@...el.com> To: Masahiro Yamada <masahiroy@...nel.org> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, linux-kernel@...r.kernel.org, Jason Gunthorpe <jgg@...dia.com>, David Airlie <airlied@...il.com>, Simona Vetter <simona.vetter@...ll.ch>, linux-kbuild@...r.kernel.org, dri-devel@...ts.freedesktop.org, intel-xe@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org Subject: Re: [PATCH v2 0/4] kbuild: resurrect generic header check facility On Fri, 04 Apr 2025, Masahiro Yamada <masahiroy@...nel.org> wrote: > On Wed, Apr 2, 2025 at 9:47 PM Jani Nikula <jani.nikula@...el.com> wrote: >> >> Another go at hiding the turds. >> >> In v1 [1] I hid the build artifacts under .hdrtest subdirectories, one in each >> $(obj) directory, but the feedback from Linus [2] was to have one top level >> directory for this. >> >> This is not possible without turning the whole thing back into a generic header >> check facility. Personally, I think this is a good thing. Just look at patches >> 2-4, it's great. >> >> The main reason we've been doing this in the subsystem/driver level at all is >> the opposition from the kbuild maintainer. We'd very much like for Masahiro to >> support us in our efforts, but without that support, we're limited to hacking in >> the subsystem/driver Makefiles. >> >> BR, >> Jani. >> >> >> [1] https://lore.kernel.org/r/20250401121830.21696-1-jani.nikula@intel.com >> >> [2] https://lore.kernel.org/r/CAHk-=wiP0ea7xq2P3ryYs6xGWoqTw1E4jha67ZbJkaFrjqUdkQ@mail.gmail.com >> >> >> Cc: Linus Torvalds <torvalds@...ux-foundation.org> >> Cc: Masahiro Yamada <masahiroy@...nel.org> > > > NACK. > > This does not solve any real issue, except making Linus happy > - Sure, he is happy as long as he no longer has to see the turds. > > This patch merely hides the turds by moving all the > header-test build artifacts under the .header-check/ > and introducing CONFIG_HEADER_CHECK_DISABLE. > Yes, Linus advised us to hide all the turds because he cares > about the TAB-completion. > > But to me, from the Kbuild perspective, this is not a solution at all. > What is worse, Jani is pushing his workaround into the common > Kbuild Makefiles, which I maintain, and he is even make this > broken feature widely accessible. > > I agree with Jason. > His idea sounds better, although I do not have enough time > for investigating it further or implementing it now. > > > At least, this patchset is not something we should rush into. I expect much better rationale for NAKs than this. The shortcoming in this series is that it offloads the decision *which* header files to check to the subsystems and drivers that actually opt-in to having the header files to be checked. Because you have to opt-in anyway, because not everyone wants this. This makes concrete forward progress, and enables subsystems (like drm) and drivers (like i915 and xe) have their headers checked the way they want. It converts the local hacks into a generic solution. And does not block future improvements. Even with Jason's idea [1], you *still* have to start small and opt-in (i.e. the patch series at hand). You can't just start off by testing every header in one go, because it's a flag day switch. There'll be so many warnings that it's useless. This series only spotted one omission of header guards, because we've gradually cleaned stuff up. Oh, and there's the small detail that the idea is not backed up by any code or testing. I fully expect sharp and concrete technical review, but handwavy "does not solve any real issue", "workaround", and "broken feature" comments don't help anyone. With this type of antagonistic rather than encouraging attitude towards contributions, there's just no way I can justify to myself (or my employer) spending more time on what looks like a wild goose chase. I have zero confidence that no matter what I do I'd get approval from you. And this is the primary reason subsystems and drivers hack up stuff in their little corners of the kernel instead of sticking their necks out and trying to generalize anything. BR, Jani. [1] https://lore.kernel.org/r/20250401191455.GC325917@nvidia.com > >> Cc: David Airlie <airlied@...il.com> >> Cc: Simona Vetter <simona.vetter@...ll.ch> >> Cc: linux-kbuild@...r.kernel.org >> Cc: dri-devel@...ts.freedesktop.org >> Cc: intel-xe@...ts.freedesktop.org >> Cc: intel-gfx@...ts.freedesktop.org >> >> >> Jani Nikula (4): >> kbuild: add generic header check facility >> drm: switch to generic header check facility >> drm/i915: switch to generic header check facility >> drm/xe: switch to generic header check facility >> >> drivers/gpu/drm/Kconfig | 2 +- >> drivers/gpu/drm/Makefile | 15 +-------------- >> drivers/gpu/drm/i915/Makefile | 14 ++------------ >> drivers/gpu/drm/xe/Makefile | 10 ++-------- >> drivers/gpu/drm/xe/xe_pcode_api.h | 4 ++++ >> include/drm/Makefile | 15 +-------------- >> init/Kconfig | 25 +++++++++++++++++++++++++ >> scripts/Makefile.build | 13 +++++++++++++ >> scripts/Makefile.lib | 7 +++++++ >> 9 files changed, 56 insertions(+), 49 deletions(-) >> >> -- >> 2.39.5 >> -- Jani Nikula, Intel
Powered by blists - more mailing lists