Re: panic with tg_shares_up again?

[Ken Chen]

On Tue, Dec 23, 2008 at 3:46 PM, Ken Chen <kenchen@xxxxxxxxxx> wrote:
> And from my local build of linux-tip with the patch, I have the
> following assembly:
>     1  ffffffff8023b74f:  48 8b 88 a8 00 00 00    mov    0xa8(%rax),%rcx
>     2  ffffffff8023b756:  48 c7 45 d0 00 00 00    movq   $0x0,-0x30(%rbp)
>     3  ffffffff8023b75d:  00
>     4  ffffffff8023b75e:  48 85 c9                test   %rcx,%rcx
>     5  ffffffff8023b761:  0f 95 c0                setne  %al
>     6  ffffffff8023b764:  84 45 af                test   %al,-0x51(%rbp)
>     7  ffffffff8023b767:  74 15                   je     ffffffff8023b77e
>     8  ffffffff8023b769:  48 8b 45 b8             mov    -0x48(%rbp),%rax
>     9  ffffffff8023b76d:  31 d2                   xor    %edx,%edx
>    10  ffffffff8023b76f:  48 0f af c1             imul   %rcx,%rax
>    11  ffffffff8023b773:  48 f7 75 b0             divq   -0x50(%rbp)
>
> line 6 is the compare against sd_rq_weight, but it was only to one
> byte instead of the entire unsigned long.
>
> /me scratching my head ....

After a couple of hours joggling with type cast and different order in
which these two variables are checked, the compiler I'm using seems to
insist only check one byte out of sd_rq_weight.  I give up for the day
and removed the 'static' function declaration of
update_group_shares_cpu().  Without the 'static', the assembly looks
alright to me.

I will ask compiler expert to see what's wrong with this code.  For
now, the following add on patch seems generate correct x86 assembly
code.

on top of git commit d71f5a7c8bf9cd7c74159a53e522e363f2eddaf5

diff --git a/kernel/sched.c b/kernel/sched.c
index 413f16f..7f6b801 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -1494,7 +1494,7 @@
 /*
  * Calculate and set the cpu's group shares.
  */
-static void
+void
 update_group_shares_cpu(struct task_group *tg, int cpu, unsigned long boost,
 			unsigned long sd_shares, unsigned long sd_rq_weight)
 {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/