linux-kernel - Re: [Question] Hooks for scheduler tracing (CFS)

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]

Date:	Thu, 26 Jul 2007 13:19:57 +0530
From:	ankita@...ibm.com (Ankita Garg)
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Arjan van de Ven <arjan@...radead.org>, linux@...mer.net,
	LKML <linux-kernel@...r.kernel.org>,
	RT-Users <linux-rt-users@...r.kernel.org>,
	mathieu.desnoyers@...ymtl.ca
Subject: Re: [Question] Hooks for scheduler tracing (CFS)

On Thu, Jul 26, 2007 at 09:35:20AM +0200, Ingo Molnar wrote:
> 
> * Ankita Garg <ankita@...ibm.com> wrote:
> 
> > The probe point did get triggered, and soon after that I had the 
> > following in dmesg, leading to system hang...
> > 
> > BUG: scheduling while atomic: softirq-rcu/3/0x00000004/52, CPU#3
> > 
> > Call Trace:
> >  <#DB>  [<ffffffff81033555>] __schedule_bug+0x4b/0x4f
> >  [<ffffffff8128b414>] __sched_text_start+0xcc/0xaaa
> >  [<ffffffff8100b574>] dump_trace+0x248/0x25d
> >  [<ffffffff81068334>] print_traces+0x9/0xb
> >  [<ffffffff8100b5e5>] show_trace+0x5c/0x64
> >  [<ffffffff8128c1c2>] schedule+0xe4/0x104
> >  [<ffffffff8128d10c>] rt_spin_lock_slowlock+0xfc/0x19e
> >  [<ffffffff8128d9de>] __rt_spin_lock+0x1f/0x21
> >  [<ffffffff8128d9e9>] rt_spin_lock+0x9/0xb
> >  [<ffffffff88387dcc>]
> > :stap_c1a10b1292b5f87a563f56d89ddfc765_606:_stp_print_flush+0x5f/0xdf
> >  [<ffffffff88389e41>]
> > :stap_c1a10b1292b5f87a563f56d89ddfc765_606:probe_1493+0x1f6/0x257
> >  [<ffffffff8838bdc3>]
> 
> I'd suggest to not put a probe into a preempt-off section - put it to 
> the beginning and to the end of schedule() to capture context-switches. 
> _stp_print_flush() is in the systemtap-generated module, right? Maybe 
> the problem is resolved by changing that spinlock to use raw_spinlock_t 
> / DEFINE_RAW_SPIN_LOCK.

Yes, _stp_print_flush is in the systemtap-generated kprobe module.
Placing the probe at the beginning of schedule() also has the same
effect. Will try by changing the spinlock to raw_spinlock_t...

> 
> 
> 	Ingo

-- 
Regards,
Ankita Garg (ankita@...ibm.com)
Linux Technology Center
IBM India Systems & Technology Labs, 
Bangalore, India   
-
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/