Re: 2.6.13-rc4-mm1: Divide by zero in find_idlest_group

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 12 Aug 2005 01:21 am, Dave Kleikamp wrote:
> I encounted this trap on a 2-way i386 box running 2.6.13-rc4-mm1:
>
> [70347.743727] divide error: 0000 [#2]
> [70347.752979] PREEMPT SMP DEBUG_PAGEALLOC
> [70347.773060] last sysfs file: /devices/pnp0/00:11/id
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0xc0119556 in find_idlest_group (sd=0xc1084dc0, p=0xc3b96030, this_cpu=0)
>     at sched.c:1033
> 1033                    target_load = target_load * rq->prio_bias /
> rq->nr_running;
>
> (gdb) where
> #0  0xc0119556 in find_idlest_group (sd=0xc1084dc0, p=0xc3b96030,
> this_cpu=0) at sched.c:1033
> #1  0xc0119744 in sched_balance_self (cpu=0, flag=4) at sched.c:1151
> #2  0xc011a63f in sched_exec () at sched.c:1840
> #3  0xc016cacb in do_execve (filename=0xc3e35000 "/bin/sh",
> argv=0xbfff512c, envp=0xbfff6010, regs=0xa00) at exec.c:1162
> #4  0xc0101b5a in sys_execve (regs=
>       {ebx = -1208173323, ecx = -1073786580, edx = -1073782768, esi =
> -1073782768, edi = -1208107392, ebp = -1073786620, eax = 11, xds = 123, xes
> = -1072693125, orig_eax = 11, eip = -1208664822, xcs = 115, eflags = 658,
> esp = -1073786628, xss = 123}) at process.c:787 #5  0xc0102fdd in
> syscall_call () at current.h:9
> #6  0xb7fcbcf5 in ?? ()
>
> print *(struct runqueue *)0xc108c400
> $1 = {lock = {raw_lock = {slock = 1}, break_lock = 0}, nr_running = 0,
>   prio_bias = 0, cpu_load = {0, 0, 0}, nr_switches = 8877527,
>   nr_uninterruptible = 132930, expired_timestamp = 0,
>   timestamp_last_tick = 70347783539837, curr = 0xc1103550, idle =
> 0xc1103550, prev_mm = 0x0, active = 0xc108c8c0, expired = 0xc108c448,
> arrays = {{ nr_active = 0, bitmap = {0, 0, 0, 0, 4096}, queue = {{next =
> 0xc108c460, prev = 0xc108c460}, {next = 0xc108c468, prev = 0xc108c468}, {
> next = 0xc108c470, prev = 0xc108c470}, {next = 0xc108c478, prev =
> 0xc108c478}, {next = 0xc108c480, prev = 0xc108c480}, { next = 0xc108c488,
> prev = 0xc108c488}, {next = 0xc108c490,
>
> in __source_load, it looks like rq_nr_running must have changed between
> the if statement and the divide:
>
>         if (rq->nr_running > 1 || (idle == NOT_IDLE && rq->nr_running))
>                 /*
>                  * If we are busy rebalancing the load is biased by
>                  * priority to create 'nice' support across cpus. When
>                  * idle rebalancing we should only bias the source_load if
>                  * there is more than one task running on that queue to
>                  * prevent idle rebalance from trying to pull tasks from a
>                  * queue with only one running task.
>                  */
>                 source_load = source_load * rq->prio_bias / rq->nr_running;
>
> Should there be any locking around this?  Or should the value of
> rq->nr_running be saved to a local variable as in this untested patch?

Very sneaky..

On initial inspection your patch makes complete sense. I see no point in 
adding locking to this function as the accuracy is not critical. Want to give 
your patch a run and then push it to akpm? Thanks!

Cheers,
Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux