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
| ||
|
Date: Sat, 19 Nov 2022 09:50:52 +0100 From: Thomas Gleixner <tglx@...utronix.de> To: Andi Kleen <ak@...ux.intel.com>, Peter Zijlstra <peterz@...radead.org> Cc: "Jiri Slaby (SUSE)" <jirislaby@...nel.org>, linux-kernel@...r.kernel.org, Andy Lutomirski <luto@...nel.org>, Martin Liska <mliska@...e.cz>, Jiri Slaby <jslaby@...e.cz> Subject: Re: [PATCH 18/46] entry, lto: Mark raw_irqentry_exit_cond_resched() as __visible On Fri, Nov 18 2022 at 16:50, Andi Kleen wrote: >> Sure, they can play around with it but that does not require to merge >> all this nonsensical ballast for a half thought out compiler. > > You are referring to __visible? > > TBH I don't understand the problem. In general __visible is useful > documentation, so you know something is used from assembler or other > strange contexts. Doing such things explicitly marked instead of > implicitly hidden and they just happen to work by accident > seems cleaner to me. Seems cleaner is really not a technical argument. Visible is completely useless. Either a symbol is global and therefore reachable from any point in the final "executable" or it's not. Whether that reference is in assembly or from a pointer, static key or whatever does not matter at all. There is no such thing as a 'strange context'. Nothing works here by accident. A global symbol is a global symbol whether it's defined or referenced from C or from ASM or from any other programming language does not matter at all. > I can also see the __visible markings being useful for other purposes, > e.g. static analysis tools or dynamic instrumentation like the various > sanitizers. Everything that is referenced outside the normal code that > the compiler sees may need some special handling. All you have is 'may need' and 'I can see'. Where is the actual use case? >> If they want to do that they can apply the pile of patches as provided >> and play around. > > It's very difficult to maintain out of tree, while in tree it's much > simpler. Sure. Lots of things are simpler to maintain in tree, but that's not an argument for merging anything. > I think Linux should support its primary compiler well and not give up > due to relatively small obstacles. It's not an obstacle. It's a fundamental broken model. clang has proven that it can be done proper, so there is no reason to proliferate the inferior. While you might consider gcc to be the primary compiler, that might have been true a decade ago. A lot of people prefer clang as their primary compiler simply because its saner and the maintainers behind it are working with us and not trying to inflict their half baken crap on us to spare themself the work to do it right. Thanks, tglx
Powered by blists - more mailing lists