linux-kernel - Re: [PATCH 58/61] dynamic debug: combine dprintk and dynamic printk

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]

Message-ID: <20090325105023.GL2341@elte.hu>
Date:	Wed, 25 Mar 2009 11:50:23 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Greg Kroah-Hartman <gregkh@...e.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, Jason Baron <jbaron@...hat.com>,
	Greg Banks <gnb@....com>
Subject: Re: [PATCH 58/61] dynamic debug: combine dprintk and dynamic printk

* Greg Kroah-Hartman <gregkh@...e.de> wrote:

> From: Jason Baron <jbaron@...hat.com>
> 
> This patch combines Greg Bank's dprintk() work with the existing 
> dynamic printk patchset, we are now calling it 'dynamic debug'.
> 
> The new feature of this patchset is a richer /debugfs control file 
> interface, (an example output from my system is at the bottom), 
> which allows fined grained control over the the debug output. The 
> output can be controlled by function, file, module, format string, 
> and line number.

Hm, dunno this overlaps quite a bit with existing tracing 
facilities.

There seems to be serious consolidation potential here, if you want 
to reduce code and want to cooperate with existing tracing 
facilities.

In particlar, this facility seems to be a subset of what is already 
possible via trace_printk(). We could make every dprintk() site show 
up in /debug/tracing/events/dprintk/, and make it possible to toggle 
them on/off individually.

Furthermore it would also be possible to use the user-defined per 
tracepoint filter expression facility. That way each dprintk site 
can be (optionally) tailored individually.

For example we could enable such use:

  echo 'pid == 1234' > /debug/tracing/events/dprintk/fs/lockd/svc4proc.c:71/filter
  echo 1             > /debug/tracing/events/dprintk/fs/lockd/svc4proc.c:71/enabled

To tailor the following dprintk() in fs/lockd/svc4proc.c (line 71):

  static __be32
  nlm4svc_proc_null(struct svc_rqst *rqstp, void *argp, void *resp)
  {
          dprintk("lockd: NULL          called\n");
          return rpc_success;
  }

To only be printed for PID 1234.

Per subsystem filters would be available too. The subsystem 
maintainers dont have to do anything but place dprintk() calls - 
they'll show up under /debug/tracing/events/dprintk/ automatically.

Would you be interested in this?

	Ingo
--
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/