linux-kernel - Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAA+hA=QJJ7zeHn+Luruyq2eGU+HWsv4UmFz7RNqkeaTP0eerUQ@mail.gmail.com>
Date:	Wed, 27 Apr 2016 16:53:06 +0800
From:	Dong Aisheng <dongas86@...il.com>
To:	Stefan Agner <stefan@...er.ch>
Cc:	Fabio Estevam <festevam@...il.com>,
	Shawn Guo <shawnguo@...nel.org>,
	Lucas Stach <l.stach@...gutronix.de>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	mingo@...hat.com, "kernel@...gutronix.de" <kernel@...gutronix.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-clk@...r.kernel.org,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled

On Wed, Apr 27, 2016 at 3:28 PM, Stefan Agner <stefan@...er.ch> wrote:
> On 2016-04-26 19:56, Fabio Estevam wrote:
>> On Tue, Apr 26, 2016 at 11:45 PM, Dong Aisheng <dongas86@...il.com> wrote:
>>
>>>> We need to firstly understand why this is happening.  The .prepare hook
>>>> is defined to be non-atomic context, and so that we call sleep function
>>>> in there.  We did everything right.  Why are we getting the warning?  If
>>>> I'm correct, this warning only happens on i.MX7D.  Why is that?
>>>>
>>>
>>> This is mainly caused by during kernel early booting, there's only one init idle
>>> task running.
>>> See:
>>> void __init sched_init(void)
>>> {
>>> .....
>>>         /*
>>>          * Make us the idle thread. Technically, schedule() should not be
>>>          * called from this thread, however somewhere below it might be,
>>>          * but because we are the idle thread, we just pick up running again
>>>          * when this runqueue becomes "idle".
>>>          */
>>>         init_idle(current, smp_processor_id());
>>> ...
>>> }
>>>
>>> And the idle sched class indicates it's not valid to schedule for idle task.
>>> const struct sched_class idle_sched_class = {
>>>         /* .next is NULL */
>>>         /* no enqueue/yield_task for idle tasks */
>>>
>>>         /* dequeue is not valid, we print a debug message there: */
>>>         .dequeue_task           = dequeue_task_idle,
>>> ...........
>>>
>>> }
>>>
>>> /*
>>>  * It is not legal to sleep in the idle task - print a warning
>>>  * message if some code attempts to do it:
>>>  */
>>> static void
>>> dequeue_task_idle(struct rq *rq, struct task_struct *p, int flags)
>>> {
>>>         raw_spin_unlock_irq(&rq->lock);
>>>         printk(KERN_ERR "bad: scheduling from the idle thread!\n");
>>>         dump_stack();
>>>         raw_spin_lock_irq(&rq->lock);
>>> }
>>>
>>>
>>> Below is the full log of imx7d booting FYI.
>>
>> This does not answer Shawn's question: why do we see this only on mx7d?
>
> I was wondering that too.... My theory is that either on i.MX 6 the
> clocks enable almost instantly leading to no sleep, or they are just
> bootloader/firmware on...?
>

Yes, for core plls, they're already enabled in bootloader.
We observed this issue on MX7D is because we rudely enable all clocks
for it and MX7D AV PLLs which will lead to sleep reveals this issue.

Regards
Dong Aisheng

> --
> Stefan