All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Wang <wangyun@linux.vnet.ibm.com>
To: Fengguang Wu <fengguang.wu@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Suresh Siddha <suresh.b.siddha@intel.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: BUG: scheduling while atomic, under native_smp_prepare_cpus()
Date: Mon, 20 Aug 2012 17:42:22 +0800	[thread overview]
Message-ID: <5032067E.20505@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120820092744.GA3668@localhost>

On 08/20/2012 05:27 PM, Fengguang Wu wrote:
> Hi Michael,
> 
> On Mon, Aug 20, 2012 at 05:20:35PM +0800, Michael Wang wrote:
>> On 08/17/2012 09:49 PM, Fengguang Wu wrote:
>>
>> Hi, FengGuang
>>
>> native_smp_prepare_cpus has already disabled the preempt before
>> reach __irq_alloc_descs(), and sleep in mutex_lock() cause the bug.
>>
>> May be the follow patch could help to solve the issue(actually I
>> think the true problem should be in _cond_resched...).
> 
> Is this a debug patch? Since what it does is to conditionally disable
> the warning.

No, I use this as a solution, it should work as the bug reported in boot
process before init_post called.

We have some reference from __might_sleep which also avoid the check if
system has not fully booted, so I think this way is acceptable, but I'm
not the one to make decision...

> 
>> I can't do test by my self since I can't reproduce the issue on my
>> machine, the kernel_init thread never got a need sched flag set at
>> that moment in my case...
> 
> I'll try it and report back :)

Appreciate :)

Regards,
Michael Wang
> 
> Thanks,
> Fengguang
> 
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 4376c9f..3396c33 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -3321,7 +3321,8 @@ static inline void schedule_debug(struct task_struct *prev)
>>          * schedule() atomically, we ignore that path for now.
>>          * Otherwise, whine if we are scheduling when we should not be.
>>          */
>> -       if (unlikely(in_atomic_preempt_off() && !prev->exit_state))
>> +       if (unlikely(in_atomic_preempt_off() && !prev->exit_state
>> +                                       && system_state == SYSTEM_RUNNING))
>>                 __schedule_bug(prev);
>>         rcu_sleep_check();
>>
>>
>>> Trace one (full config/dmesg attached):
>>>
>>> [    0.042794] init IO_APIC IRQs [    0.043305]  apic 2 pin 0 not 
>>> connected [    0.043953] BUG: scheduling while atomic: 
>>> swapper/0/1/0x10000002 [    0.044017] no locks held by swapper/0/1. [
>>> 0.044692] Pid: 1, comm: swapper/0 Not tainted 
>>> 3.6.0-rc1-00420-gb7aebb9 #34 [    0.045861] Call Trace: [ 0.048071] 
>>> [<c106361e>] __schedule_bug+0x5e/0x70 [    0.048890] [<c1b28701>] 
>>> __schedule+0x91/0xb10 [    0.049660]  [<c14472ea>] ? 
>>> vsnprintf+0x33a/0x450 [    0.050444]  [<c1060006>] ? 
>>> lg_local_lock+0x6/0x70 [    0.051256]  [<c14fb5b1>] ? 
>>> wait_for_xmitr+0x31/0x90 [    0.052019]  [<c144fd55>] ? 
>>> do_raw_spin_unlock+0xa5/0xf0 [    0.052903]  [<c1b2a532>] ? 
>>> _raw_spin_unlock+0x22/0x30 [    0.053759]  [<c105cdbb>] ? 
>>> up+0x1b/0x70 [    0.054421]  [<c1065d6b>] __cond_resched+0x1b/0x30 [
>>>  0.055228]  [<c1b292d5>] _cond_resched+0x45/0x50 [    0.056020] 
>>> [<c1b26c58>] mutex_lock_nested+0x28/0x370 [    0.056884]
>>> [<c1034222>] ? console_unlock+0x3a2/0x4e0 [    0.057741]
>>> [<c1ac8559>] __irq_alloc_descs+0x39/0x1c0 [    0.058589]
>>> [<c10223bc>] io_apic_setup_irq_pin+0x2c/0x310 [    0.060042]
>>> [<c20638df>] setup_IO_APIC+0x101/0x744 [    0.060878]  [<c1021d51>] ?
>>>  clear_IO_APIC+0x31/0x50 [    0.061695]  [<c20600f4>] 
>>> native_smp_prepare_cpus+0x538/0x680 [    0.062644]  [<c2056a91>] ? 
>>> do_one_initcall+0x12c/0x12c [    0.063517]  [<c2056a91>] ? 
>>> do_one_initcall+0x12c/0x12c [    0.064016]  [<c2056adc>] 
>>> kernel_init+0x4b/0x17f [    0.064790]  [<c2056a91>] ? 
>>> do_one_initcall+0x12c/0x12c [    0.065660]  [<c1b2bbd6>] 
>>> kernel_thread_helper+0x6/0x10 [    0.066592] IOAPIC[0]: Set routing 
>>> entry (2-1 -> 0x41 -> IRQ 1 Mode:0 Active:0 Dest:1) [    0.068045] 
>>> IOAPIC[0]: Set routing entry (2-2 -> 0x51 -> IRQ 0 Mode:0 Active:0 
>>> Dest:1)
>>>
>>> Trace two (triggered by another config):
>>>
>>> [    0.288018] tlb_flushall_shift is 0xffffffff [    0.316019] 
>>> Freeing SMP alternatives: 20k freed [    0.364022] BUG: scheduling 
>>> while atomic: swapper/0/1/0x10000002 [    0.364022] no locks held by
>>>  swapper/0/1. [    0.368023] Pid: 1, comm: swapper/0 Not tainted 
>>> 3.6.0-rc1 #1 [    0.368023] Call Trace: [    0.368023]  [<79812e23>]
>>>  __schedule_bug+0x41/0x53 [    0.372023]  [<79820393>] 
>>> __schedule+0x62/0x488 [    0.376023]  [<792d17ae>] ? 
>>> radix_tree_lookup+0xa/0xc [    0.376023]  [<79071f4e>] ? 
>>> rcu_irq_exit+0x61/0x66 [    0.376023]  [<79026be7>] ? 
>>> irq_exit+0x60/0x6c [    0.376023]  [<790035df>] ? do_IRQ+0x6c/0x80 [
>>>  0.380023]  [<7903d794>] __cond_resched+0x16/0x26 [    0.380023] 
>>> [<79820888>] _cond_resched+0x13/0x1c [    0.380023]  [<7909f30a>] 
>>> slab_pre_alloc_hook.isra.44+0x2e/0x33 [    0.380023]  [<790a09c6>] 
>>> kmem_cache_alloc+0x1b/0xbb [    0.384024]  [<792ce416>] ? 
>>> alloc_cpumask_var_node+0x1a/0x72 [    0.384024]  [<792ce416>] 
>>> alloc_cpumask_var_node+0x1a/0x72 [    0.384024]  [<792ce486>] 
>>> alloc_cpumask_var+0xb/0xd [    0.388024]  [<792ce493>] 
>>> zalloc_cpumask_var+0xb/0xd [    0.388024]  [<79bfe1fd>] 
>>> native_smp_prepare_cpus+0x93/0x380 [    0.388024]  [<79bf6a7e>] ? 
>>> do_one_initcall+0x10c/0x10c [    0.388024]  [<79bf6ac6>] 
>>> kernel_init+0x48/0x16e [    0.392024]  [<79bf6a7e>] ? 
>>> do_one_initcall+0x10c/0x10c [    0.392024]  [<7982241e>] 
>>> kernel_thread_helper+0x6/0xd [    0.400025] smpboot: SMP disabled [ 
>>> 0.400025] Performance Events:
>>>
>>> Thanks, Fengguang
>>>
> 


  reply	other threads:[~2012-08-20  9:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-17 13:49 BUG: scheduling while atomic, under native_smp_prepare_cpus() Fengguang Wu
2012-08-20  9:20 ` Michael Wang
2012-08-20  9:27   ` Fengguang Wu
2012-08-20  9:42     ` Michael Wang [this message]
2012-08-21 16:50       ` Fengguang Wu
2012-08-22  2:07         ` Michael Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5032067E.20505@linux.vnet.ibm.com \
    --to=wangyun@linux.vnet.ibm.com \
    --cc=fengguang.wu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.