Prev: hibernation hangs with ATA errors (lockup_detector bug)
Next: aha1542 oops caused by new request_irq routines
From: Boaz Harrosh on 31 May 2010 10:30
On 05/31/2010 04:55 PM, Toralf Förster wrote:
>
> Borislav Petkov wrote at 22:17:38
>> LKML-Reference: <201005271944.09541.toralf.foerster(a)gmx.de>
>> Signed-off-by: Borislav Petkov <bp(a)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
>> @@ -0,0 +1,6 @@
>> +#ifndef _ASM_UM_HWEIGHT_H
>> +#define _ASM_UM_HWEIGHT_H
>> +
>> +#include <asm-generic/bitops/arch_hweight.h>
>> +
>> +#endif
>>
> This patch does not to solve the reported issue by me.
>

Watch out. It did fix it for me but only after a deep
clean. (mrproper) Makefile does not pick up this dependency.

Also I could not use my 2.6.34 config file. I had to do
make defconfig, and then xconfig all my extra stuff. But
this is regular for any Kernel upgrade and UML.

It does fix my setup. (Wouldn't load before this)
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paolo Giarrusso on 12 Jun 2010 09:40
On Sun, May 30, 2010 at 23:09, H. Peter Anvin <hpa(a)zytor.com> wrote:
> On 05/30/2010 01:17 PM, Borislav Petkov wrote:
>>>> This bothers me, because it really feels like something is fundamentally
>>>> broken in UML tryingto track the upstream architecture, and this is just
>>>> a bandage.
>>>
>>> First of all, scratch that patch. It is indeed dumb idea to sprinkle UML
>>> special cases in x86 just because they include it.
>>>
>>> Which begs the question why _is_ UML sucking in x86 stuff and can anyone
>>> provide us with some sensible reasons? Because if there aren't any, it
>>> is their includes that should be fixed. Let me see what I can do to
>>> redirect hweight stuff properly...
>>
>> Ok, AFAICT UML is sucking in the includes of the sub-architecture the
>> UML "guest" is running on. See below¹ for the whole gcc string make
>> executes. Among the switches is
>>
>> "-I/home/boris/kernel/linux-2.6/arch/x86/include"
>>
>> so there will be no untangling today. Instead, we could do another
>> bandaid which is confined to UML include space only and redirect
>> arch_hweight.h includes to the generic ones. Check this out, it seems to
>> work here:
>>
>
> 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.

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
copy_from_user and staff like that (I recall the exception handler was
set at run-time).

Indeed, arch/um/kernel/um_arch.c:apply_alternatives() is empty. And I
mean, implementing it is not so trivial (unlike exception handling),
simply because it requires making the binary mapping writable, and I'm
not sure UML does it already.

A third note is that UML links with glibc, so it can have a different
calling convention from the kernel. Say, on x86 32bit regparm doesn't
work (in fact, -mregparm is set in arch/x86/Makefile and not in
arch/x86/Makefile_32.cpu). And since popcnt is supported on 32bit, it
might in theory make a difference for that case. But maybe those flags
are simply fine, I didn't recheck the possible calling conventions.

Good bye!
--
Paolo Giarrusso - Ph.D. Student
http://www.informatik.uni-marburg.de/~pgiarrusso/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Borislav Petkov on 12 Jun 2010 10:20
From: Paolo Giarrusso <p.giarrusso(a)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.
>
> 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
> copy_from_user and staff like that (I recall the exception handler was
> set at run-time).
>
> Indeed, arch/um/kernel/um_arch.c:apply_alternatives() is empty. And I
> mean, implementing it is not so trivial (unlike exception handling),
> simply because it requires making the binary mapping writable, and I'm
> not sure UML does it already.

Which would mean that UML doesn't use alternatives at all and uses the
instructions which are meant to be replaced instead, no? In that case,
fixing this is either by rerouting the includes (easiest, already in
-tip) or adding alternatives support (harder, needs volunteers :)).

> A third note is that UML links with glibc, so it can have a different
> calling convention from the kernel. Say, on x86 32bit regparm doesn't
> work (in fact, -mregparm is set in arch/x86/Makefile and not in
> arch/x86/Makefile_32.cpu). And since popcnt is supported on 32bit, it
> might in theory make a difference for that case. But maybe those flags
> are simply fine, I didn't recheck the possible calling conventions.

If this is also the case, the -fcall-saved-* stuff won't work on UML and
yet another way of doing "call *func" from within asm("...") and making
sure the callee doesn't clobber caller's regs will be needed for UML.

--
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paolo Giarrusso on 12 Jun 2010 12:10
On Sat, Jun 12, 2010 at 16:18, Borislav Petkov <bp(a)alien8.de> wrote:
> From: Paolo Giarrusso <p.giarrusso(a)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
>> copy_from_user and staff like that (I recall the exception handler was
>> set at run-time).

>> Indeed, arch/um/kernel/um_arch.c:apply_alternatives() is empty. And I
>> mean, implementing it is not so trivial (unlike exception handling),
>> simply because it requires making the binary mapping writable, and I'm
>> not sure UML does it already.

> Which would mean that UML doesn't use alternatives at all and uses the
> instructions which are meant to be replaced instead, no?

Exactly.

> In that case,
> fixing this is either by rerouting the includes (easiest, already in
> -tip) or adding alternatives support (harder, needs volunteers :)).

Well, even doing just nothing should work, if you fix the trivial
thing above (which at least for 64bit should work).

>> A third note is that UML links with glibc, so it can have a different
>> calling convention from the kernel. Say, on x86 32bit regparm doesn't
>> work (in fact, -mregparm is set in arch/x86/Makefile and not in
>> arch/x86/Makefile_32.cpu). And since popcnt is supported on 32bit, it
>> might in theory make a difference for that case. But maybe those flags
>> are simply fine, I didn't recheck the possible calling conventions.

> If this is also the case, the -fcall-saved-* stuff won't work on UML and
> yet another way of doing "call *func" from within asm("...") and making
> sure the callee doesn't clobber caller's regs will be needed for UML.

Hmpf... anyway, 64bit should be fine since there's just one calling
convention, everywhere, and already regparm'ed.

Regards
--
Paolo Giarrusso - Ph.D. Student
http://www.informatik.uni-marburg.de/~pgiarrusso/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paolo Giarrusso on 14 Jun 2010 06:30
2010/6/14 Toralf Förster <toralf.foerster(a)gmx.de>:
>
> Borislav Petkov wrote at 16:10:58
>> Did you do 'make mrproper' before rebuilding UML with it?
>
> Today I started with a clean git tree (cloned Linus tree) and got this :
>
> foerste(a)n22 ~ $ start_uml.sh

Can you enable frame pointers to get an accurate stack trace? x86 can
be accurate without, but I don't think this was ever implemented for
UML.
Because I'm not sure if below cfq_close_cooperator is being called
again, or if it's just garbage (as I guess). Anyway, it's still likely
that the crash is on hweight32.

Also, it'd be interesting to diff your configuration with the one used
by people the patch works for. Say,
$ grep HWEIGHT .config
(if there are any CFLAGS set in ARcH_HWEIGHT_CFLAGS, that would be a
problem as far as I see).

> EIP: 0073:[<081c4fcb>] CPU: 0 Not tainted ESP: 007b:08300b40 EFLAGS: 00010297
>    Not tainted
> EAX: 00000000 EBX: 190d2000 ECX: ffff8aea EDX: 00000000
> ESI: 191f4930 EDI: 191ef900 EBP: 191f4930 DS: 007b ES: 007b
> 08300794:  [<0805e65f>] segv_handler+0x3f/0x60
> 083007a4:  [<081c4fcb>] cfq_close_cooperator+0x4b/0x180
> 083007b0:  [<0806eec5>] sig_handler_common+0x55/0xa0
> 083007f0:  [<081c4fcb>] cfq_close_cooperator+0x4b/0x180
> 08300828:  [<0806f063>] sig_handler+0x23/0x40
> 08300830:  [<0806f2bd>] handle_signal+0x5d/0xa0
> 08300850:  [<080715f7>] hard_handler+0x17/0x20
> 0830089c:  [<081c4fcb>] cfq_close_cooperator+0x4b/0x180
> 08300a4c:  [<0807a3eb>] T.696+0x9b/0xc0
> 08300a74:  [<08079425>] enqueue_task+0x45/0x60
> 08300a94:  [<0807945f>] activate_task+0x1f/0x30
> 08300aa0:  [<080794d8>] try_to_wake_up+0x68/0xa0
> 08300acc:  [<0809369f>] autoremove_wake_function+0x2f/0x60
> 08300ae8:  [<0807754f>] __wake_up_common+0x4f/0x80
> 08300b18:  [<08077837>] __wake_up+0x47/0x60
> 08300b3c:  [<081c4fc6>] cfq_close_cooperator+0x46/0x180
> 08300b58:  [<081c5440>] cfq_completed_request+0x2a0/0x560
> 08300b90:  [<081b7fce>] elv_completed_request+0x7e/0xf0
> 08300ba8:  [<081b98f6>] __blk_put_request+0x36/0xf0
> 08300bc0:  [<081b9b26>] blk_finish_request+0x176/0x1d0
> 08300be0:  [<081b9ea1>] blk_end_bidi_request+0x41/0x60
> 08300bf4:  [<08068e8d>] ubd_intr+0x2d/0xf0
> 08300c14:  [<080a6b32>] handle_IRQ_event+0x32/0xc0
> 08300c34:  [<080a6c1b>] __do_IRQ+0x5b/0xb0
> 08300c50:  [<0805b364>] do_IRQ+0x24/0x40
> 08300c5c:  [<0805b59b>] sigio_handler+0x5b/0x80
> 08300c70:  [<0806eec5>] sig_handler_common+0x55/0xa0
> 08300c80:  [<0806efb5>] real_alarm_handler+0x35/0x40
> 08300cbc:  [<080739f0>] __delay+0x20/0x30
> 08300ce8:  [<0806f063>] sig_handler+0x23/0x40
> 08300cf0:  [<0806f2bd>] handle_signal+0x5d/0xa0
> 08300d10:  [<080715f7>] hard_handler+0x17/0x20


--
Paolo Giarrusso - Ph.D. Student
http://www.informatik.uni-marburg.de/~pgiarrusso/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2
Prev: hibernation hangs with ATA errors (lockup_detector bug)
Next: aha1542 oops caused by new request_irq routines