linux-kernel - Re: [RFC PATCH 03/11] Annotate core code that should not be traced

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, 3 Jan 2008 13:34:46 -0500
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Christoph Hellwig <hch@...radead.org>,
	Gregory Haskins <ghaskins@...ell.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	"William L. Irwin" <sparclinux@...r.kernel.org>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [RFC PATCH 03/11] Annotate core code that should not be traced

* Steven Rostedt (rostedt@...dmis.org) wrote:
> 
> 
 ....
> >
> > >  {
> > >  	struct irq_desc *desc = irq_desc + irq;
> > >  	struct irqaction *action;
> > > Index: linux-compile.git/kernel/lockdep.c
> > > ===================================================================
> > > --- linux-compile.git.orig/kernel/lockdep.c	2007-12-20 01:00:29.000000000 -0500
> > > +++ linux-compile.git/kernel/lockdep.c	2007-12-20 01:00:48.000000000 -0500
> > > @@ -270,14 +270,14 @@ static struct list_head chainhash_table[
> > >  	((key1) >> (64-MAX_LOCKDEP_KEYS_BITS)) ^ \
> > >  	(key2))
> > >
> > > -void lockdep_off(void)
> > > +notrace void lockdep_off(void)
> > >  {
> > >  	current->lockdep_recursion++;
> > >  }
> > >
> >
> > Due to interrupt disabling in your tracing code I suppose.
> 
> probably. Again, this came from the RT patch. And this stuff has been in
> the patch for ages. So some of it was just plain paranoia. Others were
> needed for some kind of tracing.
> 
> BTW, I'm curious? How do you handle NMIs and tracing. Do you use a
> separate buffer for storing your data on NMIs or do you have some kind of
> cmpxchg that can atomically reserve parts of the trace buffer?
> 

Because I want to deal with weird cases like :

kernel calling tracing code, causing a user-space page fault, which
calls the tracer, which could be interrupted by an NMI, it would become
tricky to find out how many contexts could be stacked in the worse case
for each architecture. Therefore, using a cmpxchg-based algorithm is the
solution I used. However, in order to make this fast, I extented the
"local atomic operations" to offer a local_cmpxchg.

Mathieu


-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
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/