* [PATCH] ARM: BUG() dies silently
@ 2011-03-31 20:15 Omar Ramirez Luna
2011-04-01 1:47 ` Simon Glass
2011-09-17 6:07 ` Rabin Vincent
0 siblings, 2 replies; 18+ messages in thread
From: Omar Ramirez Luna @ 2011-03-31 20:15 UTC (permalink / raw)
To: linux-arm-kernel
There are some cases where the code generated for BUG() results
into an infinite while loop without causing a null dereference,
this ends on a kernel being stuck on a loop and the user without
a clue of what happened.
E.g.: lib/scatterlist.c : __sg_alloc_table
BUG_ON(nents > max_ents);
438: 9a000000 bls 440 <__sg_alloc_table+0x20>
43c: eafffffe b 43c <__sg_alloc_table+0x1c>
Adding volatile makes the compiler to avoid optimizations on this
code, which makes the panic to occur:
BUG_ON(nents > max_ents);
438: 9a000002 bls 448 <__sg_alloc_table+0x28>
43c: e3a03000 mov r3, #0
440: e5833000 str r3, [r3]
444: eafffffc b 43c <__sg_alloc_table+0x1c>
Seen with gnu/linux cs arm-2010q1-202 and arm2010.09-50.
Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
---
If needed I can change:
./arch/arm/mach-clps711x/include/mach/io.h:
#define __raw_readsb(p,d,l) do { *(int *)0 = 0; } while (0)
./arch/arm/mach-clps711x/include/mach/io.h:
#define __raw_readsl(p,d,l) do { *(int *)0 = 0; } while (0)
./arch/arm/mach-clps711x/include/mach/io.h:
#define __raw_writesb(p,d,l) do { *(int *)0 = 0; } while (0)
./arch/arm/mach-clps711x/include/mach/io.h:
#define __raw_writesl(p,d,l) do { *(int *)0 = 0; } while (0)
./arch/arm/kernel/traps.c: *(int *)0 = 0;
arch/arm/include/asm/bug.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
index 4d88425..a58d863 100644
--- a/arch/arm/include/asm/bug.h
+++ b/arch/arm/include/asm/bug.h
@@ -12,7 +12,7 @@ extern void __bug(const char *file, int line) __attribute__((noreturn));
#else
/* this just causes an oops */
-#define BUG() do { *(int *)0 = 0; } while (1)
+#define BUG() do { *(volatile int *)0 = 0; } while(1)
#endif
--
1.7.1
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH] ARM: BUG() dies silently
2011-03-31 20:15 [PATCH] ARM: BUG() dies silently Omar Ramirez Luna
@ 2011-04-01 1:47 ` Simon Glass
2011-04-01 8:44 ` Stephen Boyd
2011-09-17 6:07 ` Rabin Vincent
1 sibling, 1 reply; 18+ messages in thread
From: Simon Glass @ 2011-04-01 1:47 UTC (permalink / raw)
To: linux-arm-kernel
You might try the generic bug patch and see if it also fixes this
problem - Simon
On Thu, Mar 31, 2011 at 1:15 PM, Omar Ramirez Luna <omar.ramirez@ti.com> wrote:
> There are some cases where the code generated for BUG() results
> into an infinite while loop without causing a null dereference,
> this ends on a kernel being stuck on a loop and the user without
> a clue of what happened.
>
> E.g.: lib/scatterlist.c : __sg_alloc_table
>
> ? ? ? ?BUG_ON(nents > max_ents);
> ?438: ? 9a000000 ? ? ? ?bls ? ? 440 <__sg_alloc_table+0x20>
> ?43c: ? eafffffe ? ? ? ?b ? ? ? 43c <__sg_alloc_table+0x1c>
>
> Adding volatile makes the compiler to avoid optimizations on this
> code, which makes the panic to occur:
>
> ? ? ? ?BUG_ON(nents > max_ents);
> ?438: ? 9a000002 ? ? ? ?bls ? ? 448 <__sg_alloc_table+0x28>
> ?43c: ? e3a03000 ? ? ? ?mov ? ? r3, #0
> ?440: ? e5833000 ? ? ? ?str ? ? r3, [r3]
> ?444: ? eafffffc ? ? ? ?b ? ? ? 43c <__sg_alloc_table+0x1c>
>
> Seen with gnu/linux cs arm-2010q1-202 and arm2010.09-50.
>
> Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
> ---
>
> If needed I can change:
> ./arch/arm/mach-clps711x/include/mach/io.h:
> ? ? ? ?#define __raw_readsb(p,d,l) ?do { *(int *)0 = 0; } while (0)
> ./arch/arm/mach-clps711x/include/mach/io.h:
> ? ? ? ?#define __raw_readsl(p,d,l) ?do { *(int *)0 = 0; } while (0)
> ./arch/arm/mach-clps711x/include/mach/io.h:
> ? ? ? ?#define __raw_writesb(p,d,l) do { *(int *)0 = 0; } while (0)
> ./arch/arm/mach-clps711x/include/mach/io.h:
> ? ? ? ?#define __raw_writesl(p,d,l) do { *(int *)0 = 0; } while (0)
> ./arch/arm/kernel/traps.c: ? ? ?*(int *)0 = 0;
>
>
> ?arch/arm/include/asm/bug.h | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
> index 4d88425..a58d863 100644
> --- a/arch/arm/include/asm/bug.h
> +++ b/arch/arm/include/asm/bug.h
> @@ -12,7 +12,7 @@ extern void __bug(const char *file, int line) __attribute__((noreturn));
> ?#else
>
> ?/* this just causes an oops */
> -#define BUG() ? ? ? ? ?do { *(int *)0 = 0; } while (1)
> +#define BUG() ? ? ? ? ?do { *(volatile int *)0 = 0; } while(1)
>
> ?#endif
>
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] ARM: BUG() dies silently
2011-04-01 1:47 ` Simon Glass
@ 2011-04-01 8:44 ` Stephen Boyd
2011-04-01 22:29 ` Simon Glass
0 siblings, 1 reply; 18+ messages in thread
From: Stephen Boyd @ 2011-04-01 8:44 UTC (permalink / raw)
To: linux-arm-kernel
On 3/31/2011 6:47 PM, Simon Glass wrote:
> You might try the generic bug patch and see if it also fixes this
> problem - Simon
It probably won't because presumably Omar has CONFIG_BUG=n otherwise
Omar would have sent a patch against __bug() in arch/arm/kernel/traps.c
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] ARM: BUG() dies silently
2011-04-01 8:44 ` Stephen Boyd
@ 2011-04-01 22:29 ` Simon Glass
2011-04-03 7:15 ` Stephen Boyd
0 siblings, 1 reply; 18+ messages in thread
From: Simon Glass @ 2011-04-01 22:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi Stephen,
Sorry for the confusion, but in fact I was talking about the patch to
make ARM use the generic bug handling via an undef instruction instead
of calling ______bug() or writing to memory address 0. Please see
here:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6808/1
Regards,
Simon
On Fri, Apr 1, 2011 at 1:44 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 3/31/2011 6:47 PM, Simon Glass wrote:
>> You might try the generic bug patch and see if it also fixes this
>> problem - Simon
>
> It probably won't because presumably Omar has CONFIG_BUG=n otherwise
> Omar would have sent a patch against __bug() in arch/arm/kernel/traps.c
>
> --
> Sent by an employee of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] ARM: BUG() dies silently
2011-04-01 22:29 ` Simon Glass
@ 2011-04-03 7:15 ` Stephen Boyd
2011-04-05 1:55 ` Simon Glass
2011-04-05 2:29 ` Ramirez Luna, Omar
0 siblings, 2 replies; 18+ messages in thread
From: Stephen Boyd @ 2011-04-03 7:15 UTC (permalink / raw)
To: linux-arm-kernel
(Please stop top posting)
On 4/1/2011 3:29 PM, Simon Glass wrote:
> Hi Stephen,
>
> Sorry for the confusion, but in fact I was talking about the patch to
> make ARM use the generic bug handling via an undef instruction instead
> of calling ______bug() or writing to memory address 0. Please see
> here:
>
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6808/1
Yes I've seen your patch (and even posted comments on it which have not
been responded to).
Correct me if I'm wrong, but that patch with CONFIG_BUG=n would lead to
the same error that Omar is seeing because the code only modifies the
bug infrastructure when CONFIG_BUG=y.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] ARM: BUG() dies silently
2011-04-03 7:15 ` Stephen Boyd
@ 2011-04-05 1:55 ` Simon Glass
2011-04-05 17:36 ` Stephen Boyd
2011-04-05 2:29 ` Ramirez Luna, Omar
1 sibling, 1 reply; 18+ messages in thread
From: Simon Glass @ 2011-04-05 1:55 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, Apr 3, 2011 at 12:15 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> (Please stop top posting)
>
> On 4/1/2011 3:29 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> Sorry for the confusion, but in fact I was talking about the patch to
>> make ARM use the generic bug handling via an undef instruction instead
>> of calling ______bug() or writing to memory address 0. Please see
>> here:
>>
>> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6808/1
>
> Yes I've seen your patch (and even posted comments on it which have not
> been responded to).
Hi Stephen,
Not yet! Don't worry I will get to it. I like the suggestion and am
pleased that you pointed me to it, thank you.
> Correct me if I'm wrong, but that patch with CONFIG_BUG=n would lead to
> the same error that Omar is seeing because the code only modifies the
> bug infrastructure when CONFIG_BUG=y.
Well if CONFIG_BUG=n then there is no bug infrastructure, The whole
file is skipped and it falls back to the asm-generic/bug.h which has
even more #ifdefs in it. But I think we end up here:
#define BUG() do {} while(0)
After all the patch removes the *(int*)0 = 0 code by virtue of
CONFIG_GENERIC_BUG=y, right? If I have this wrong then I will have to
break out the C preprocessor...
Regards,
Simon
>
> --
> Sent by an employee of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] ARM: BUG() dies silently
2011-04-05 1:55 ` Simon Glass
@ 2011-04-05 17:36 ` Stephen Boyd
0 siblings, 0 replies; 18+ messages in thread
From: Stephen Boyd @ 2011-04-05 17:36 UTC (permalink / raw)
To: linux-arm-kernel
On 4/4/2011 6:55 PM, Simon Glass wrote:
> On Sun, Apr 3, 2011 at 12:15 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> Yes I've seen your patch (and even posted comments on it which have not
>> been responded to).
> Hi Stephen,
>
> Not yet! Don't worry I will get to it. I like the suggestion and am
> pleased that you pointed me to it, thank you.
>
Great!
>> Correct me if I'm wrong, but that patch with CONFIG_BUG=n would lead to
>> the same error that Omar is seeing because the code only modifies the
>> bug infrastructure when CONFIG_BUG=y.
> Well if CONFIG_BUG=n then there is no bug infrastructure, The whole
> file is skipped and it falls back to the asm-generic/bug.h which has
> even more #ifdefs in it. But I think we end up here:
>
> #define BUG() do {} while(0)
>
> After all the patch removes the *(int*)0 = 0 code by virtue of
> CONFIG_GENERIC_BUG=y, right? If I have this wrong then I will have to
> break out the C preprocessor...
>
Ah you're right. Too many ifdefs going on there.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] ARM: BUG() dies silently
2011-04-03 7:15 ` Stephen Boyd
2011-04-05 1:55 ` Simon Glass
@ 2011-04-05 2:29 ` Ramirez Luna, Omar
2011-04-05 5:46 ` Simon Glass
1 sibling, 1 reply; 18+ messages in thread
From: Ramirez Luna, Omar @ 2011-04-05 2:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi Simon, Stephen,
On Sun, Apr 3, 2011 at 2:15 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> (Please stop top posting)
>
> On 4/1/2011 3:29 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> Sorry for the confusion, but in fact I was talking about the patch to
>> make ARM use the generic bug handling via an undef instruction instead
>> of calling ______bug() or writing to memory address 0. Please see
>> here:
>>
>> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6808/1
>
> Yes I've seen your patch (and even posted comments on it which have not
> been responded to).
>
> Correct me if I'm wrong, but that patch with CONFIG_BUG=n would lead to
> the same error that Omar is seeing because the code only modifies the
> bug infrastructure when CONFIG_BUG=y.
I am using CONFIG_BUG=y, however I don't have CONFIG_DEBUG_BUGVERBOSE
and hence I fall into the part which doesn't print the file and the
line where the BUG was found.
With Simon's patch if my .config had:
CONFIG_BUG=y
CONFIG_GENERIC_BUG is not set
CONFIG_DEBUG_BUGVERBOSE is not set
I would fall into the same BUG definition that is causing issues:
#define BUG() do { *(int *)0 = 0; } while (1)
OTOH, is not like "Use generic BUG() handler" gives the choice of
removing GENERIC_BUG given that it is not prompted in menuconfig and
auto selected, if this is the intention is there any reason to keep
the #else part of /* not CONFIG_GENERIC_BUG */? there is no way we can
use it with this patch, right?
Regards,
Omar
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] ARM: BUG() dies silently
2011-04-05 2:29 ` Ramirez Luna, Omar
@ 2011-04-05 5:46 ` Simon Glass
2011-04-05 16:02 ` Ramirez Luna, Omar
0 siblings, 1 reply; 18+ messages in thread
From: Simon Glass @ 2011-04-05 5:46 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Apr 4, 2011 at 7:29 PM, Ramirez Luna, Omar <omar.ramirez@ti.com> wrote:
...
> I am using CONFIG_BUG=y, however I don't have CONFIG_DEBUG_BUGVERBOSE
> and hence I fall into the part which doesn't print the file and the
> line where the BUG was found.
>
> With Simon's patch if my .config had:
>
> CONFIG_BUG=y
> CONFIG_GENERIC_BUG is not set
In this case the patch is like a nop.
> CONFIG_DEBUG_BUGVERBOSE is not set
>
> I would fall into the same BUG definition that is causing issues:
>
> #define BUG() ? ? ? ? ? do { *(int *)0 = 0; } while (1)
>
> OTOH, is not like "Use generic BUG() handler" gives the choice of
> removing GENERIC_BUG given that it is not prompted in menuconfig and
> auto selected, if this is the intention is there any reason to keep
> the #else part of /* not CONFIG_GENERIC_BUG */? there is no way we can
> use it with this patch, right?
Well, er, the intention is that you use the patch. I kept the old code
around since people can then simply change the Kconfig option and be
back where they were, as indeed you have. I would be happy to remove
the old behavior, but I was concerned about a possible roasting in
this forum. Changing long-established behavior is sometimes tricky.
Regards,
Simon
>
> Regards,
>
> Omar
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] ARM: BUG() dies silently
2011-04-05 5:46 ` Simon Glass
@ 2011-04-05 16:02 ` Ramirez Luna, Omar
2011-04-05 16:43 ` Simon Glass
0 siblings, 1 reply; 18+ messages in thread
From: Ramirez Luna, Omar @ 2011-04-05 16:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Tue, Apr 5, 2011 at 12:46 AM, Simon Glass <sjg@chromium.org> wrote:
> On Mon, Apr 4, 2011 at 7:29 PM, Ramirez Luna, Omar <omar.ramirez@ti.com> wrote:
> ...
>> I am using CONFIG_BUG=y, however I don't have CONFIG_DEBUG_BUGVERBOSE
>> and hence I fall into the part which doesn't print the file and the
>> line where the BUG was found.
>>
>> With Simon's patch if my .config had:
>>
>> CONFIG_BUG=y
>> CONFIG_GENERIC_BUG is not set
>
> In this case the patch is like a nop.
>
>> CONFIG_DEBUG_BUGVERBOSE is not set
>>
>> I would fall into the same BUG definition that is causing issues:
>>
>> #define BUG() ? ? ? ? ? do { *(int *)0 = 0; } while (1)
>>
>> OTOH, is not like "Use generic BUG() handler" gives the choice of
>> removing GENERIC_BUG given that it is not prompted in menuconfig and
>> auto selected, if this is the intention is there any reason to keep
>> the #else part of /* not CONFIG_GENERIC_BUG */? there is no way we can
>> use it with this patch, right?
>
> Well, er, the intention is that you use the patch. I kept the old code
> around since people can then simply change the Kconfig option and be
> back where they were, as indeed you have. I would be happy to remove
> the old behavior, but I was concerned about a possible roasting in
> this forum. Changing long-established behavior is sometimes tricky.
Yes, but you can't change the Kconfig because it is not prompted with
your patch, if that was the intention then an option to de/select
GENERIC_BUG or not is needed:
arch/arm/Kconfig
@@ -204,6 +204,10 @@ config MMU
Select if you want MMU-based virtualised addressing space
support by paged memory management. If unsure, say 'Y'.
+config GENERIC_BUG
+ bool "Generic BUG"
+ default y
+ depends on BUG
Regards,
Omar
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] ARM: BUG() dies silently
2011-04-05 16:02 ` Ramirez Luna, Omar
@ 2011-04-05 16:43 ` Simon Glass
0 siblings, 0 replies; 18+ messages in thread
From: Simon Glass @ 2011-04-05 16:43 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 5, 2011 at 9:02 AM, Ramirez Luna, Omar <omar.ramirez@ti.com> wrote:
> Hi,
>
> On Tue, Apr 5, 2011 at 12:46 AM, Simon Glass <sjg@chromium.org> wrote:
>> On Mon, Apr 4, 2011 at 7:29 PM, Ramirez Luna, Omar <omar.ramirez@ti.com> wrote:
>> ...
>>> OTOH, is not like "Use generic BUG() handler" gives the choice of
>>> removing GENERIC_BUG given that it is not prompted in menuconfig and
>>> auto selected, if this is the intention is there any reason to keep
>>> the #else part of /* not CONFIG_GENERIC_BUG */? there is no way we can
>>> use it with this patch, right?
>>
>> Well, er, the intention is that you use the patch. I kept the old code
>> around since people can then simply change the Kconfig option and be
>> back where they were, as indeed you have. I would be happy to remove
>> the old behavior, but I was concerned about a possible roasting in
>> this forum. Changing long-established behavior is sometimes tricky.
>
> Yes, but you can't change the Kconfig because it is not prompted with
> your patch, if that was the intention then an option to de/select
> GENERIC_BUG or not is needed:
>
> arch/arm/Kconfig
> @@ -204,6 +204,10 @@ config MMU
> ? ? ? ? ?Select if you want MMU-based virtualised addressing space
> ? ? ? ? ?support by paged memory management. If unsure, say 'Y'.
>
> +config GENERIC_BUG
> + ? ? ? bool "Generic BUG"
> + ? ? ? default y
> + ? ? ? depends on BUG
Yes that's right, it is a manual edit. But if there are no objections
I will create a patch to remove this and replace the old bug
infrastructure entirely. - Simon
>
> Regards,
>
> Omar
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] ARM: BUG() dies silently
2011-03-31 20:15 [PATCH] ARM: BUG() dies silently Omar Ramirez Luna
2011-04-01 1:47 ` Simon Glass
@ 2011-09-17 6:07 ` Rabin Vincent
2011-09-19 14:26 ` Ramirez Luna, Omar
1 sibling, 1 reply; 18+ messages in thread
From: Rabin Vincent @ 2011-09-17 6:07 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Apr 1, 2011 at 01:45, Omar Ramirez Luna <omar.ramirez@ti.com> wrote:
> There are some cases where the code generated for BUG() results
> into an infinite while loop without causing a null dereference,
> this ends on a kernel being stuck on a loop and the user without
> a clue of what happened.
>
> E.g.: lib/scatterlist.c : __sg_alloc_table
>
> ? ? ? ?BUG_ON(nents > max_ents);
> ?438: ? 9a000000 ? ? ? ?bls ? ? 440 <__sg_alloc_table+0x20>
> ?43c: ? eafffffe ? ? ? ?b ? ? ? 43c <__sg_alloc_table+0x1c>
>
> Adding volatile makes the compiler to avoid optimizations on this
> code, which makes the panic to occur:
>
> ? ? ? ?BUG_ON(nents > max_ents);
> ?438: ? 9a000002 ? ? ? ?bls ? ? 448 <__sg_alloc_table+0x28>
> ?43c: ? e3a03000 ? ? ? ?mov ? ? r3, #0
> ?440: ? e5833000 ? ? ? ?str ? ? r3, [r3]
> ?444: ? eafffffc ? ? ? ?b ? ? ? 43c <__sg_alloc_table+0x1c>
>
> Seen with gnu/linux cs arm-2010q1-202 and arm2010.09-50.
>
> Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
If the "Use generic BUG() handler" patch is only scheduled for the next
merge window and not for 3.1, can this patch be merged instead for 3.1
and -stable? This problem is easily seen with GCC 4.6.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] ARM: BUG() dies silently
2011-09-17 6:07 ` Rabin Vincent
@ 2011-09-19 14:26 ` Ramirez Luna, Omar
2011-09-19 14:43 ` Russell King - ARM Linux
0 siblings, 1 reply; 18+ messages in thread
From: Ramirez Luna, Omar @ 2011-09-19 14:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi
On Sat, Sep 17, 2011 at 1:07 AM, Rabin Vincent <rabin@rab.in> wrote:
> If the "Use generic BUG() handler" patch is only scheduled for the next
> merge window and not for 3.1, can this patch be merged instead for 3.1
> and -stable? ?This problem is easily seen with GCC 4.6.
I can send it for both and let the maintainers decide.
Russell, do you give your ack?
Regards,
Omar
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] ARM: BUG() dies silently
2011-09-19 14:26 ` Ramirez Luna, Omar
@ 2011-09-19 14:43 ` Russell King - ARM Linux
2011-09-19 16:59 ` Russell King - ARM Linux
0 siblings, 1 reply; 18+ messages in thread
From: Russell King - ARM Linux @ 2011-09-19 14:43 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 19, 2011 at 09:26:49AM -0500, Ramirez Luna, Omar wrote:
> Hi
>
> On Sat, Sep 17, 2011 at 1:07 AM, Rabin Vincent <rabin@rab.in> wrote:
> > If the "Use generic BUG() handler" patch is only scheduled for the next
> > merge window and not for 3.1, can this patch be merged instead for 3.1
> > and -stable? ?This problem is easily seen with GCC 4.6.
>
> I can send it for both and let the maintainers decide.
>
> Russell, do you give your ack?
I think it's too large a change for -stable and 3.1 - let's get it into
3.2 first, and make sure no one sees any regressions there. Then we can
think about submitting it to stable once its proven itself.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] ARM: BUG() dies silently
2011-09-19 14:43 ` Russell King - ARM Linux
@ 2011-09-19 16:59 ` Russell King - ARM Linux
2011-09-19 18:02 ` Simon Glass
0 siblings, 1 reply; 18+ messages in thread
From: Russell King - ARM Linux @ 2011-09-19 16:59 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 19, 2011 at 03:43:13PM +0100, Russell King - ARM Linux wrote:
> On Mon, Sep 19, 2011 at 09:26:49AM -0500, Ramirez Luna, Omar wrote:
> > Hi
> >
> > On Sat, Sep 17, 2011 at 1:07 AM, Rabin Vincent <rabin@rab.in> wrote:
> > > If the "Use generic BUG() handler" patch is only scheduled for the next
> > > merge window and not for 3.1, can this patch be merged instead for 3.1
> > > and -stable? ?This problem is easily seen with GCC 4.6.
> >
> > I can send it for both and let the maintainers decide.
> >
> > Russell, do you give your ack?
>
> I think it's too large a change for -stable and 3.1 - let's get it into
> 3.2 first, and make sure no one sees any regressions there. Then we can
> think about submitting it to stable once its proven itself.
And we're seeing link failures with the patch in the kernel, so it's
*definitely* not stable material as it stands, even if the current code
is a problem for GCC 4.6.
Regressions trump bug fixes.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] ARM: BUG() dies silently
2011-09-19 16:59 ` Russell King - ARM Linux
@ 2011-09-19 18:02 ` Simon Glass
2011-09-19 18:25 ` Russell King - ARM Linux
0 siblings, 1 reply; 18+ messages in thread
From: Simon Glass @ 2011-09-19 18:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi Russell,
On Mon, Sep 19, 2011 at 9:59 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Sep 19, 2011 at 03:43:13PM +0100, Russell King - ARM Linux wrote:
>> On Mon, Sep 19, 2011 at 09:26:49AM -0500, Ramirez Luna, Omar wrote:
>> > Hi
>> >
>> > On Sat, Sep 17, 2011 at 1:07 AM, Rabin Vincent <rabin@rab.in> wrote:
>> > > If the "Use generic BUG() handler" patch is only scheduled for the next
>> > > merge window and not for 3.1, can this patch be merged instead for 3.1
>> > > and -stable? ?This problem is easily seen with GCC 4.6.
>> >
>> > I can send it for both and let the maintainers decide.
>> >
>> > Russell, do you give your ack?
>>
>> I think it's too large a change for -stable and 3.1 - let's get it into
>> 3.2 first, and make sure no one sees any regressions there. ?Then we can
>> think about submitting it to stable once its proven itself.
>
> And we're seeing link failures with the patch in the kernel, so it's
> *definitely* not stable material as it stands, even if the current code
> is a problem for GCC 4.6.
>
> Regressions trump bug fixes.
Can you point me to the link failures please?
Regards,
Simon
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] ARM: BUG() dies silently
2011-09-19 18:02 ` Simon Glass
@ 2011-09-19 18:25 ` Russell King - ARM Linux
2011-09-19 18:32 ` Ramirez Luna, Omar
0 siblings, 1 reply; 18+ messages in thread
From: Russell King - ARM Linux @ 2011-09-19 18:25 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 19, 2011 at 11:02:08AM -0700, Simon Glass wrote:
> Hi Russell,
>
> On Mon, Sep 19, 2011 at 9:59 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Sep 19, 2011 at 03:43:13PM +0100, Russell King - ARM Linux wrote:
> >> On Mon, Sep 19, 2011 at 09:26:49AM -0500, Ramirez Luna, Omar wrote:
> >> > Hi
> >> >
> >> > On Sat, Sep 17, 2011 at 1:07 AM, Rabin Vincent <rabin@rab.in> wrote:
> >> > > If the "Use generic BUG() handler" patch is only scheduled for the next
> >> > > merge window and not for 3.1, can this patch be merged instead for 3.1
> >> > > and -stable? ?This problem is easily seen with GCC 4.6.
> >> >
> >> > I can send it for both and let the maintainers decide.
> >> >
> >> > Russell, do you give your ack?
> >>
> >> I think it's too large a change for -stable and 3.1 - let's get it into
> >> 3.2 first, and make sure no one sees any regressions there. ?Then we can
> >> think about submitting it to stable once its proven itself.
> >
> > And we're seeing link failures with the patch in the kernel, so it's
> > *definitely* not stable material as it stands, even if the current code
> > is a problem for GCC 4.6.
> >
> > Regressions trump bug fixes.
>
> Can you point me to the link failures please?
There's two emails during the last couple of months on lakml:
3.1-rc1 link failure
Link failures due to __bug_table in current -next
The former I looked into and came to the conclusion that the only way to
solve it is to stop using asm-generic/vmlinux.lds.S in its entirety and
go back to hand-coding ARMs vmlinux.lds file. No one's come forward
with any better suggestion to fix this, so I'm getting very close to
having to make a decision over this. I think I'm going to have to drop
the generic bug support for the time being.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] ARM: BUG() dies silently
2011-09-19 18:25 ` Russell King - ARM Linux
@ 2011-09-19 18:32 ` Ramirez Luna, Omar
0 siblings, 0 replies; 18+ messages in thread
From: Ramirez Luna, Omar @ 2011-09-19 18:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Mon, Sep 19, 2011 at 1:25 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> I think I'm going to have to drop the generic bug support for the time being.
In this case then my patch can targeted for 3.1 and -stable, right? I
abandoned my change because the generic bug patch was the better
solution in the long term, but if it is being delayed I can submit
mine with your blessing.
https://lkml.org/lkml/2011/3/31/490
It just forces the compiler to generate the right code through
volatile, and while at it I could fix the other similar situations
(also noted in the patch).
Omar
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2011-09-19 18:32 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-31 20:15 [PATCH] ARM: BUG() dies silently Omar Ramirez Luna
2011-04-01 1:47 ` Simon Glass
2011-04-01 8:44 ` Stephen Boyd
2011-04-01 22:29 ` Simon Glass
2011-04-03 7:15 ` Stephen Boyd
2011-04-05 1:55 ` Simon Glass
2011-04-05 17:36 ` Stephen Boyd
2011-04-05 2:29 ` Ramirez Luna, Omar
2011-04-05 5:46 ` Simon Glass
2011-04-05 16:02 ` Ramirez Luna, Omar
2011-04-05 16:43 ` Simon Glass
2011-09-17 6:07 ` Rabin Vincent
2011-09-19 14:26 ` Ramirez Luna, Omar
2011-09-19 14:43 ` Russell King - ARM Linux
2011-09-19 16:59 ` Russell King - ARM Linux
2011-09-19 18:02 ` Simon Glass
2011-09-19 18:25 ` Russell King - ARM Linux
2011-09-19 18:32 ` Ramirez Luna, Omar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).