Re: [PATCH 1/3] softlockup: add sched_clock_tick() to avoid kernel warning on kgdb resume

[Dongdong Deng <libfetion@gmail.com>]

On Fri, Jan 29, 2010 at 10:51 PM, Jason Wessel
<jason.wessel@windriver.com> wrote:
> Ingo Molnar wrote:
>> * Jason Wessel <jason.wessel@windriver.com> wrote:
>>
>>
>>> @@ -118,6 +125,14 @@ void softlockup_tick(void)
>>>      }
>>>
>>>      if (touch_ts == 0) {
>>> +            if (unlikely(per_cpu(softlock_touch_sync, this_cpu))) {
>>> +                    /*
>>> +                     * If the time stamp was touched atomically
>>> +                     * make sure the scheduler tick is up to date.
>>> +                     */
>>> +                    per_cpu(softlock_touch_sync, this_cpu) = false;
>>> +                    sched_clock_tick();
>>> +            }
>>>              __touch_softlockup_watchdog();
>>>              return;
>>>
>>
>> Shouldnt just all of touch_softlockup_watchdog() gain this new
>> sched_clock_tick() call, instead of doing this ugly flaggery? Or would that
>> lock up or misbehave in other ways in some cases?
>>
>> That would also make the patch much simpler i guess, as we'd only have the
>> chunk above.
>>
>
> We have already been down that road, and it breaks other cases.
>
> http://lkml.org/lkml/2009/7/28/204
>
> Specifically the test case of:
>
> echo 3 > /proc/sys/kernel/softlockup_thresh
>
> And then some kernel code in a thread like:
>        local_irq_disable();
>        printk("Disable local irq for 11 seconds\n");
>        mdelay(11000);
>        local_irq_enable();

Hi Jason,

Maybe this problem was fixed by
commit baf48f6577e581a9adb8fe849dc80e24b21d171d - "softlock: fix false
panic which can occur if softlockup_thresh is reduced".

Thanks,
Dongdong

>
>
> I could consider calling sched_cpu_clock() before returning the kernel
> to normal execution, but that didn't look very safe to call from the
> exception context, which is why it was delayed until the next time the
> soft lockup code ran.
>
> Resuming from a long sleep is a ugly problem, so I am open to short term
> and long term suggestions, including a polling time API (obviously we
> would prefer not to go down that rat hole :-)
>
> Jason.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>