On Tue, Jan 26, 2021 at 08:51:55AM -0600, Josh Poimboeuf wrote: > On Tue, Jan 26, 2021 at 02:51:29PM +0100, Greg KH wrote: > > On Tue, Jan 26, 2021 at 06:44:44AM -0600, Justin Forbes wrote: > > > On Tue, Jan 26, 2021 at 2:21 AM Greg KH <greg@xxxxxxxxx> wrote: > > > > > > > > On Mon, Jan 25, 2021 at 04:07:57PM -0600, Josh Poimboeuf wrote: > > > > > On Tue, Jan 26, 2021 at 06:44:35AM +0900, Masahiro Yamada wrote: > > > > > > > > If people use a different compiler, they must be > > > > > > > > prepared for any possible problem. > > > > > > > > > > > > > > > > Using different compiler flags for in-tree and out-of-tree > > > > > > > > is even more dangerous. > > > > > > > > > > > > > > > > For example, CONFIG_GCC_PLUGIN_RANDSTRUCT is enabled > > > > > > > > for in-tree build, and then disabled for out-of-tree modules, > > > > > > > > the struct layout will mismatch, won't it? > > > > > > > > > > > > > > If you read the patch you'll notice that it handles that case, when it's > > > > > > > caused by GCC mismatch. > > > > > > > > > > > > > > However, as alluded to in the [1] footnote, it doesn't handle the case > > > > > > > where the OOT build system doesn't have gcc-plugin-devel installed. > > > > > > > Then CONFIG_GCC_PLUGIN_RANDSTRUCT gets silently disabled and the build > > > > > > > succeeds! That happens even without a GCC mismatch. > > > > > > > > > > > > > > > > > > Ah, sorry. > > > > > > > > > > > > I responded too early before reading the patch fully. > > > > > > > > > > > > But, I do not like to make RANDSTRUCT a special case. > > > > > > > > > > > > I'd rather want to stop building for any plugin. > > > > > > > > > > Other than RANDSTRUCT there doesn't seem to be any problem with > > > > > disabling them (and printing a warning) in the OOT build. Why not give > > > > > users that option? It's harmless, and will make distro's (and their > > > > > users') lives easier. > > > > > > > > > > Either GCC mismatch is ok, or it's not. Let's not half-enforce it. > > > > > > > > As I said earlier, it's not ok, we can not support it at all. > > > > > > > > > > Support and enforce are 2 completely different things. To shed a bit > > > more light on this, the real issue that prompted this was breaking CI > > > systems. As we enabled gcc plugins in Fedora, and the toolchain folks > > > went through 3 different snapshots of gcc 11 in a week. Any CI process > > > that built an out of tree module failed. I don't think this is nearly > > > as much of a concern for stable distros, as it is for CI in > > > development cycles. > > > > It's better to have an obvious break like this than to silently accept > > things and then have a much harder issue to debug at runtime, right? > > User space mixes compiler versions all the time. The C ABI is stable. > > What specifically is the harder issue you're referring to? Have you not noticed include/linux/compiler.h and all of the different changes/workarounds we do for different versions of gcc/clang/intel compilers? We have never guaranteed that a kernel module would work that was built with a different compiler than the main kernel, and I doubt we can start now. thanks, greg k-h
