lkml.org 
[lkml]   [2011]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

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