From mboxrd@z Thu Jan 1 00:00:00 1970 From: Manikandan Ramachandran Subject: Re: problem in kzalloc or rt_spin_lock_fastlock? Date: Fri, 10 Sep 2010 09:50:38 -0700 Message-ID: References: <8EA2C2C4116BF44AB370468FBF85A7770179FAA964@orsmsx504.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "linux-rt-users@vger.kernel.org" To: "Sydir, Jerry" Return-path: Received: from mail-ww0-f44.google.com ([74.125.82.44]:50962 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755943Ab0IJQuk convert rfc822-to-8bit (ORCPT ); Fri, 10 Sep 2010 12:50:40 -0400 Received: by wwb13 with SMTP id 13so49479wwb.1 for ; Fri, 10 Sep 2010 09:50:38 -0700 (PDT) In-Reply-To: <8EA2C2C4116BF44AB370468FBF85A7770179FAA964@orsmsx504.amr.corp.intel.com> Sender: linux-rt-users-owner@vger.kernel.org List-ID: i did come across this issue, in different context. I worked around this by not using kzalloc, instead by having static allocation. I guess this is one of the RT related changes to make atomic calls pree= mptible. HTH, Mani On Thu, Sep 9, 2010 at 2:28 PM, Sydir, Jerry wr= ote: > Hello all, > > I had posted a question a few weeks ago concerning problems with perf= and oprofile when running on the 2.6.33.7-rt29 kernel. I received help= on how to fix the problem with perf, but no replies about oprofile. Ha= ving looked into the oprofile problem more carefully, I have a more spe= cific question that I'm hoping somebody can answer. > > > Below is the stack trace that I received when starting the oprofile d= aemon. (It's the same trace that I included in my previous post). Filli= ng in some of the macros and inlined functions the call sequence is as = follows: Ppro_setup_cntrs calls kzalloc with the GFP_ATOMIC flag set. A= ccording to kmalloc documentation this means that the call should not s= leep. Kmalloc calls kmem_cache_alloc_notrace, calls kmem_cache_alloc, c= alls __cache_alloc, calls _slab_irq_disable, calls get_cpu_val_locked (= a macro in which a call to rt_spin_lock is generated). Rt_spin_lock cal= ls rt_spin_lock_fastlock which has the following code: > > =A0 /* Temporary HACK! */ > 706 =A0 =A0 =A0 =A0 if (likely(!current->in_printk)) > 707 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 might_sleep(); > 708 =A0 =A0 =A0 =A0 else if (in_atomic() || irqs_disabled()) > 709 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* don't grab locks for printk in= atomic */ > 710 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return; > > Might_sleep is called and the kernel notes this as an error. I'm gues= sing that since this call did not originate in printk, might_sleep is g= etting called. > > I have very little knowledge of the inner workings of the kernel, so = I don't know whether the error is with one of the functions in the call= sequence, or with the check on line 706 which results in an unnecessar= y call to might_sleep(). I have found that although the kernel reports = an oops, the oprofile daemon and the system seem to operate correctly. = Can someone please confirm whether there is a real error here or whethe= r the problem is that might_sleep is being called unnecessarily in this= case? Can I assume that all is well with oprofile and ignore the kerne= l oops? > > Thanks in advance for your help. > Jerry Sydir > > > oprofile: using NMI interrupt. > BUG: sleeping function called from invalid context at kernel/rtmutex.= c:707 > pcnt: 2 0 in_atomic(): 1, irqs_disabled(): 1, pid: 4020, name: oprofi= led > Pid: 4020, comm: oprofiled Not tainted 2.6.33.7-rt29 #3 > Call Trace: > [] ? rt_spin_lock_fastlock+0x26/0x58 > [] ? _slab_irq_disable+0x22/0x42 > [] ? __kmalloc+0x7d/0xf0 > [] ? ppro_setup_ctrs+0x29/0x1b8 [oprofile] > [] ? ppro_setup_ctrs+0x29/0x1b8 [oprofile] > [] ? nmi_cpu_setup+0x87/0xcc [oprofile] > [] ? nmi_cpu_setup+0x0/0xcc [oprofile] > [] ? on_each_cpu+0x25/0x50 > [] ? nmi_setup+0x11d/0x14a [oprofile] > [] ? oprofile_setup+0x2d/0x86 [oprofile] > [] ? event_buffer_open+0x42/0x60 [oprofile] > [] ? __dentry_open+0x1a4/0x29a > [] ? generic_permission+0xc/0x7e > [] ? nameidata_to_filp+0x27/0x38 > [] ? event_buffer_open+0x0/0x60 [oprofile] > [] ? do_filp_open+0x439/0x843 > [] ? __do_fault+0x2bf/0x2ef > [] ? slab_irq_enable+0x45/0x79 > [] ? do_sys_open+0x4c/0xe4 > [] ? sys_open+0x1e/0x23 > [] ? sysenter_do_call+0x12/0x26 > -- > To unsubscribe from this list: send the line "unsubscribe linux-rt-us= ers" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at =A0http://vger.kernel.org/majordomo-info.html > --=20 Thanks, Manik Think twice about a tree before you take a printout -- To unsubscribe from this list: send the line "unsubscribe linux-rt-user= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html