Messages in this thread |  | | | Date | Wed, 15 Jun 2011 09:25:53 +0200 | | From | Ingo Molnar <> | | Subject | Re: [PATCH] x86, vsyscall: Fix build warning in vsyscall_64.c |
| |
* Rakib Mullick <rakib.mullick@gmail.com> wrote:
> On Wed, Jun 15, 2011 at 3:33 AM, Andrew Lutomirski <luto@mit.edu> wrote: > > On Tue, Jun 14, 2011 at 5:31 PM, Ingo Molnar <mingo@elte.hu> wrote: > >> > >> * Linus Torvalds <torvalds@linux-foundation.org> wrote: > >> > >>> On Tue, Jun 14, 2011 at 2:16 PM, Ingo Molnar <mingo@elte.hu> wrote: > >>> > > >>> > I think correctness trumps code size and turning BUG() and BUG_ON() > >>> > into a NOP is just crazy ... > >>> > >>> Umm. It's even CRAZIER to turn it into a "compiler generates random code". > >> > >> Sigh, i assumed it got turned into an infinite loop - that is what > >> i've done in a prior patch. > >> > >> You are right, unreachable() is bogus and you'd also be right to > >> suggest that i should not comment on patches after 11pm ;-) > > > > What we want is a magic GCC trick that says "don't warn about code > > paths that go through here but generate the same code as you would > > without this annotation." I don't think such a thing exists. > > > No, I don't think we need such kind of thing. I think, we should less > rely on GCC. Here, we need to reconsider the use of BUG. When > vsyscall_nr is default, it hits BUG. Here is the code comment: > > " * If we get here, then vsyscall_nr indicates that int 0xcc > * happened at an address in the vsyscall page that doesn't > * contain int 0xcc. That can't happen. " > > If that can't happen, I think we can treat it as a FAULT. So, > rather than calling BUG we can ground it into EFAULT. Does it break > ABI compatibility?
No, that BUG() is a "cannot happen on a correct kernel" so it has no ABI impact - but it might trigger if the execution environment is violated:
- hardware failure - miscompilation - data corruption by some other kernel bug - etc.
- or it might trigger in the future if someone changes the code in a way that breaks the underlying assumption.
I guess we could do a __BUG_ON() that wont be optimized away even on !CONFIG_BUG kernels but it seems a bit silly.
So can someone tell me what the assumptions of CONFIG_BUG=n are?
If CONFIG_BUG=n means "i trust the kernel, the toolchain, the kernel and the hardware to be 100% correct [or don't care if any of those are broken]" then i can only see one solution:
- leave the warning as-is. Whoever builds with CONFIG_BUG=n will have to live with the consequences of the 'impossible' happening and will have to accept the more unpredictable kernel behavior that *will* trigger in various parts of the kernel if BUG() is turned into a NOP. If any of the above 'impossible' failure modes triggers then having more undefined behavior in form of an uninitialized variable will be the least of their worry.
Thanks,
Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |