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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 26 Apr 2016 23:56:01 -0300
From:	Fabio Estevam <festevam@...il.com>
To:	Dong Aisheng <dongas86@...il.com>
Cc:	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>,
	Stefan Agner <stefan@...er.ch>, 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 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?