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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 1 Feb 2010 13:53:19 +0800
From:	Dongdong Deng <libfetion@...il.com>
To:	Jason Wessel <jason.wessel@...driver.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, kgdb-bugreport@...ts.sourceforge.net,
	"Deng, Dongdong" <Dongdong.Deng@...driver.com>,
	peterz@...radead.org
Subject: Re: [PATCH 1/3] softlockup: add sched_clock_tick() to avoid kernel 
	warning on kgdb resume

On Fri, Jan 29, 2010 at 10:51 PM, Jason Wessel
<jason.wessel@...driver.com> wrote:
> Ingo Molnar wrote:
>> * Jason Wessel <jason.wessel@...driver.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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/