headers
Boaz Harrosh | 9 Jun 2010 10:04
Favicon
Gravatar

[PATCH resend] um, hweight: Fix UML boot crash

From: Borislav Petkov <bp <at> alien8.de>

Obviously UML cannot stomach callee reg-saving trickery
introduced with d61931d89be506372d01a90d1755f6d0a9fafe2d
(x86: Add optimized popcnt variants) and oopses during boot:
http://marc.info/?l=linux-kernel&m=127522065202435&w=2

Redirect arch_hweight.h include from the x86 portion to the generic
arch_hweight.h which is a fallback to the software hweight routines.

LKML-Reference: <201005271944.09541.toralf.foerster <at> gmx.de>
Signed-off-by: Borislav Petkov <bp <at> alien8.de>
---
 arch/um/include/asm/arch_hweight.h |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)
 create mode 100644 arch/um/include/asm/arch_hweight.h

diff --git a/arch/um/include/asm/arch_hweight.h b/arch/um/include/asm/arch_hweight.h
new file mode 100644
index 0000000..c656cf4
--- /dev/null
+++ b/arch/um/include/asm/arch_hweight.h
 <at>  <at>  -0,0 +1,6  <at>  <at> 
+#ifndef _ASM_UM_HWEIGHT_H
+#define _ASM_UM_HWEIGHT_H
+
+#include <asm-generic/bitops/arch_hweight.h>
+
+#endif
-- 1.7.1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Boaz Harrosh | 9 Jun 2010 10:09
Favicon
Gravatar

Re: [PATCH resend] um, hweight: Fix UML boot crash

On 06/09/2010 11:04 AM, Boaz Harrosh wrote:
> From: Borislav Petkov <bp <at> alien8.de>
> 
> Obviously UML cannot stomach callee reg-saving trickery
> introduced with d61931d89be506372d01a90d1755f6d0a9fafe2d
> (x86: Add optimized popcnt variants) and oopses during boot:
> http://marc.info/?l=linux-kernel&m=127522065202435&w=2
> 
> Redirect arch_hweight.h include from the x86 portion to the generic
> arch_hweight.h which is a fallback to the software hweight routines.
> 
> LKML-Reference: <201005271944.09541.toralf.foerster <at> gmx.de>
> Signed-off-by: Borislav Petkov <bp <at> alien8.de>

who's going to push this ASAP. I was just (again) 3/4 through a bisect
on 2.6.35-rc2. When I finally realized "Hey that patch, I forgot".
(My concentration is not what it used to be)

Please push this, someone
Boaz

> ---
>  arch/um/include/asm/arch_hweight.h |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
>  create mode 100644 arch/um/include/asm/arch_hweight.h
> 
> diff --git a/arch/um/include/asm/arch_hweight.h b/arch/um/include/asm/arch_hweight.h
> new file mode 100644
> index 0000000..c656cf4
> --- /dev/null
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paolo Giarrusso | 12 Jun 2010 18:01
Picon
Gravatar

Re: [PATCH] x86, hweight: Fix UML boot crash

On Sat, Jun 12, 2010 at 16:18, Borislav Petkov <bp <at> alien8.de> wrote:
> From: Paolo Giarrusso <p.giarrusso <at> gmail.com>
> Date: Sat, Jun 12, 2010 at 03:34:38PM +0200
>
> Hi,
>
>> > That looks better to me, although I'm still wondering why UML can't
>> > stomach the register-saving tricks... it is not at all "obvious" why
>> > that can't be done.
>> Hi all, and sorry for the delay, I hope you still care about this.
>>
>> First, ARCH_HWEIGHT_CFLAGS should IMHO be shared with UML. I.e., moved
>> to arch/x86/Kconfig.cpu (which was born as Kconfig code shared with
>> UML), or copied in UML (it's not defined, as far as I can see).
>> Otherwise it just can't work. And I think that's it.

Just to be sure: by "that's it" I meant "this is the problem".
You didn't answer here - did you see it? What do you think? Can you
try the one-line fix at some point?
Just to make it clear: I've not been actively developing UML (or
almost anything in kernel space) for ages (~4 years), so it's unlikely
that I'll try fixing this. It just happens that things on the UML
front stayed mostly the same, so I thought that my knowledge of the
code is still useful.

>> Second, I've been looking at arch_hweight.h to try answering as well,
>> and my question is: did somebody ever implement ALTERNATIVE support on
>> UML? When I worked on it, this thing didn't exist at all. The user
>> declared the host CPU, and we enabled features based on that. There's
>> barely code for exception tables, and we never used it to implement
(Continue reading)

Permalink | Reply | 0 comments |
headers
Geert Uytterhoeven | 12 Jun 2010 20:37

Re: [PATCH] x86, hweight: Fix UML boot crash

On Sat, Jun 12, 2010 at 18:34, Borislav Petkov <bp <at> alien8.de> wrote:
> From: Paolo Giarrusso <p.giarrusso <at> gmail.com>
> Date: Sat, Jun 12, 2010 at 06:01:44PM +0200
>
>> >> First, ARCH_HWEIGHT_CFLAGS should IMHO be shared with UML. I.e., moved
>> >> to arch/x86/Kconfig.cpu (which was born as Kconfig code shared with
>> >> UML), or copied in UML (it's not defined, as far as I can see).
>> >> Otherwise it just can't work. And I think that's it.
>>
>> Just to be sure: by "that's it" I meant "this is the problem".
>> You didn't answer here - did you see it? What do you think? Can you
>> try the one-line fix at some point?
>> Just to make it clear: I've not been actively developing UML (or
>> almost anything in kernel space) for ages (~4 years), so it's unlikely
>> that I'll try fixing this. It just happens that things on the UML
>> front stayed mostly the same, so I thought that my knowledge of the
>> code is still useful.
>
> Cool :). However, according to Geert, this doesn't fix it:
>
> http://marc.info/?l=linux-kernel&m=127522065202435&w=2
>
> It could be related to the -mregparm being broken on 32-bit UML since
> Geert's UML "guest" is 32-bit. However, even if we fix this, it won't

No, guest and host are both x86_64.

> be used since, as you said, UML doesn't do alternatives. Which means
> that it doesn't make sense fixing it until there are no alternatives -
> instead, we should simply fall back to the software hweight* stuff and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Borislav Petkov | 13 Jun 2010 08:58
Picon
Favicon

Re: [PATCH] x86, hweight: Fix UML boot crash

From: Geert Uytterhoeven <geert <at> linux-m68k.org>
Date: Sat, Jun 12, 2010 at 08:37:39PM +0200

> > Cool :). However, according to Geert, this doesn't fix it:
> >
> > http://marc.info/?l=linux-kernel&m=127522065202435&w=2
> >
> > It could be related to the -mregparm being broken on 32-bit UML since
> > Geert's UML "guest" is 32-bit. However, even if we fix this, it won't
> 
> No, guest and host are both x86_64.

Ok, maybe I don't understand UML - it's just that all address values in
the backtrace are 32-bit (e.g. RDX: 00000000ffff8aed, with the upper
8 bytes zeroed out) and I assumed that this is a 32-bit "guest" on a
64-bit host.

--

-- 
Regards/Gruss,
    Boris.

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
Permalink | Reply | 0 comments |
headers
Toralf Förster | 21 Jun 2010 14:19
Picon
Picon

crash during shutdown

Hello,

today I observed this during halt of my (Gentoo) UML image, config is attached 
:

...
 *     Shutting down lo ...                                                                                           
[ ok ]
 * Stopping syslog-ng ...Kernel panic - not syncing: Kernel mode fault at addr 
0x100104, ip 0x8061061
082fa710:  [<08277e1b>] dump_stack+0x22/0x24
082fa728:  [<08277e7e>] panic+0x61/0xdb
082fa744:  [<0805e492>] segv+0x1e2/0x2b0
082fa7fc:  [<0805e5a1>] segv_handler+0x41/0x60
082fa81c:  [<0806eb64>] sig_handler_common+0x54/0xa0
082fa898:  [<0806ed07>] sig_handler+0x27/0x50
082fa8a8:  [<0806ef5c>] handle_signal+0x5c/0xa0
082fa8cc:  [<080712d8>] hard_handler+0x18/0x20
082fa8dc:  [<b772b400>] 0xb772b400
082fabd4:  [<080614f3>] winch_interrupt+0xd3/0xe0
082fabf4:  [<080a83b5>] handle_IRQ_event+0x35/0xd0
082fac14:  [<080a84ad>] __do_IRQ+0x5d/0xb0
082fac34:  [<0805b2c5>] do_IRQ+0x25/0x40
082fac44:  [<0805b4fb>] sigio_handler+0x5b/0x80
082fac5c:  [<0806eb64>] sig_handler_common+0x54/0xa0
082facd8:  [<0806ed07>] sig_handler+0x27/0x50
082face8:  [<0806ef5c>] handle_signal+0x5c/0xa0
082fad0c:  [<080712d8>] hard_handler+0x18/0x20
082fad1c:  [<b772b400>] 0xb772b400
(Continue reading)

Permalink | Reply | 0 comments |

Gmane