On Tuesday 28 May 2013, H. Peter Anvin wrote:
> On 05/28/2013 08:43 AM, Arnd Bergmann wrote:
> >
> > Right, that is what the patch I just posted does.
> >
> > On a related note, I found that WARN_ON() can no longer be compiled
> > out since there is already code that relies on the side-effects of
On 05/28/2013 08:43 AM, Arnd Bergmann wrote:
>
> Right, that is what the patch I just posted does.
>
> On a related note, I found that WARN_ON() can no longer be compiled
> out since there is already code that relies on the side-effects of
> the condition. I assume that was an intentional change
On Tuesday 28 May 2013, H. Peter Anvin wrote:
> On 05/28/2013 01:19 AM, Ingo Molnar wrote:
> >
> > So I think the same principle applies to it as to any other debugging
> > code: it's fine to be able to turn debugging off. It's a performance
> > versus kernel robustness/determinism trade-off.
>
On 05/28/2013 01:19 AM, Ingo Molnar wrote:
>
> So I think the same principle applies to it as to any other debugging
> code: it's fine to be able to turn debugging off. It's a performance
> versus kernel robustness/determinism trade-off.
>
I suspect, rather, that BUG() should turn into a trap
On Tuesday 28 May 2013 10:19:10 Ingo Molnar wrote:
>
> * Russell King - ARM Linux wrote:
>
> > So, if you want to use this, then you should update the CONFIG_BUG text
> > to include a warning to this effect:
> >
> > Warning: if CONFIG_BUG is turned off, and control flow reaches
> > a
On 05/28/2013 04:19 PM, Ingo Molnar wrote:
>> > And I come back to one of my previous arguments - is it not better to
>> > panic() if we hit one of these conditions so that the system can try to
>> > do a panic-reboot rather than continue blindly into the unknown?
> It will often continue blindly
* Russell King - ARM Linux wrote:
> So, if you want to use this, then you should update the CONFIG_BUG text
> to include a warning to this effect:
>
> Warning: if CONFIG_BUG is turned off, and control flow reaches
> a BUG(), the system behaviour will be undefined.
>
> so that people
Chen Gang writes:
> The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
> Configure standard kernel features (expert users) > BUG() Support".
>
> But in fact, we always need it, and quite a few of architectures have
> already implemented it (e.g. alpha, arc, arm, avr32, blackf
On 05/24/2013 10:13 AM, Chen Gang wrote:
> On 05/23/2013 10:10 PM, Geert Uytterhoeven wrote:
>> On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
>> wrote:
On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>>
On 05/23/2013 10:10 PM, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
> wrote:
>> > On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>>> >> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>> > This is the problem you guys are miss
On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
wrote:
> On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>> > This is the problem you guys are missing - unreachable() means "we lose
>> > control of the CPU at this
On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> > This is the problem you guys are missing - unreachable() means "we lose
> > control of the CPU at this point".
>
> I'm absolutely aware of this. Again, the current behaviou
On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> This is the problem you guys are missing - unreachable() means "we lose
> control of the CPU at this point".
I'm absolutely aware of this. Again, the current behaviour of doing nothing
at all isn't very different from undefined behavior wh
On Thu, May 23, 2013 at 12:59:43PM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> > So, if you want to use this, then you should update the CONFIG_BUG text
> > to include a warning to this effect:
> >
> > Warning: if CONFIG_BUG is turned off, and cont
On 05/23/2013 06:59 PM, Arnd Bergmann wrote:
> You don't just want to avoid the code for printing the bug message and
> the invalid instruction, we also want the compiler to not emit the
> function call or check the enum for unexpected values. The meaning of
> BUG() is really that person writing t
Arnd Bergmann writes:
> On Thursday 23 May 2013, Geert Uytterhoeven wrote:
>> > The problem is: trying to fix that will mean the result is a larger
>> > kernel than if you just do the usual arch-implemented thing of placing
>> > an defined faulting instruction at the BUG() site - which defeats th
On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> So, if you want to use this, then you should update the CONFIG_BUG text
> to include a warning to this effect:
>
> Warning: if CONFIG_BUG is turned off, and control flow reaches
> a BUG(), the system behaviour will be undefined.
On 05/23/2013 06:04 PM, Russell King - ARM Linux wrote:
> So, if you want to use this, then you should update the CONFIG_BUG text
> to include a warning to this effect:
>
> Warning: if CONFIG_BUG is turned off, and control flow reaches
> a BUG(), the system behaviour will be undefined.
>
On Thu, May 23, 2013 at 03:09:50AM -0700, Eric W. Biederman wrote:
> Arnd Bergmann writes:
>
> > On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> >> > The problem is: trying to fix that will mean the result is a larger
> >> > kernel than if you just do the usual arch-implemented thing of plac
On Thu, May 23, 2013 at 11:39:37AM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > > The problem is: trying to fix that will mean the result is a larger
> > > kernel than if you just do the usual arch-implemented thing of placing
> > > an defined faulting instru
On 05/23/2013 05:12 PM, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 11:05 AM, Russell King - ARM Linux
> wrote:
>> > On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
>>> >> On Thu, May 23, 2013 at 9:57 AM, Chen Gang wrote:
>> > -config BUG
>> > - bool "B
On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > The problem is: trying to fix that will mean the result is a larger
> > kernel than if you just do the usual arch-implemented thing of placing
> > an defined faulting instruction at the BUG() site - which defeats the
> > purpose of turning off
On Thu, May 23, 2013 at 11:05 AM, Russell King - ARM Linux
wrote:
> On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
>> On Thu, May 23, 2013 at 9:57 AM, Chen Gang wrote:
>> > -config BUG
>> > - bool "BUG() support" if EXPERT
>> > - default y
>> > - help
>> > -
On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 9:57 AM, Chen Gang wrote:
> > -config BUG
> > - bool "BUG() support" if EXPERT
> > - default y
> > - help
> > - Disabling this option eliminates support for BUG and WARN,
> > r
On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > -config BUG
> > - bool "BUG() support" if EXPERT
> > - default y
> > - help
> > - Disabling this option eliminates support for BUG and WARN,
> > reducing
> > - the size of your kernel image and potentially q
On Thu, May 23, 2013 at 9:57 AM, Chen Gang wrote:
> The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
> Configure standard kernel features (expert users) > BUG() Support".
>
> But in fact, we always need it, and quite a few of architectures have
Sorry, but we don't. I think
The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
Configure standard kernel features (expert users) > BUG() Support".
But in fact, we always need it, and quite a few of architectures have
already implemented it (e.g. alpha, arc, arm, avr32, blackfin, cris,
frv, ia64, m68k, m
27 matches
Mail list logo
