Re: [PATCH] x86, vsyscall: Fix build warning in vsyscall_64.c

[Ingo Molnar <mingo@elte.hu>]

* 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