[lkml]   [2011]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] x86, vsyscall: Fix build warning in vsyscall_64.c

* Rakib Mullick <> wrote:

> On Wed, Jun 15, 2011 at 3:33 AM, Andrew Lutomirski <> wrote:
> > On Tue, Jun 14, 2011 at 5:31 PM, Ingo Molnar <> wrote:
> >>
> >> * Linus Torvalds <> wrote:
> >>
> >>> On Tue, Jun 14, 2011 at 2:16 PM, Ingo Molnar <> 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

- 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2011-06-15 09:29    [W:0.068 / U:13.212 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site