All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Dan Williams <dan.j.williams@intel.com>,
	"fweisbec@gmail.com" <fweisbec@gmail.com>,
	"jeyu@kernel.org" <jeyu@kernel.org>,
	"mathieu.desnoyers@efficios.com" <mathieu.desnoyers@efficios.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mingo@elte.hu" <mingo@elte.hu>,
	"chris@chris-wilson.co.uk" <chris@chris-wilson.co.uk>,
	"yuanhan.liu@linux.intel.com" <yuanhan.liu@linux.intel.com>,
	"Grumbach, Emmanuel" <emmanuel.grumbach@intel.com>
Subject: Re: [PATCH][RFC] tracing: Enable tracepoints via module parameters
Date: Wed, 21 Apr 2021 10:20:08 -0400	[thread overview]
Message-ID: <20210421102008.411af7c5@gandalf.local.home> (raw)
In-Reply-To: <5d191e26-bd00-c338-e366-b4855ac08053@rasmusvillemoes.dk>

On Wed, 21 Apr 2021 09:30:01 +0200
Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:

> On 20/04/2021 22.32, Steven Rostedt wrote:
> > On Tue, 20 Apr 2021 12:54:39 -0700
> > Dan Williams <dan.j.williams@intel.com> wrote:
> >   
> >> On Tue, Apr 20, 2021 at 5:55 AM Steven Rostedt <rostedt@goodmis.org> wrote:  
> >>>>
> >>>> The dev_dbg() filter language is attractive, it's too bad    
> >>>
> >>> Not sure what you mean by that. What filter language. Tracepoints do have a
> >>> pretty good filtering too.    
> >>  
> 
> > But you can add your own trace point, and even make it generic. That's what
> > bpf did for their bpf_trace_printk. You could convert dev_dbg() into a
> > tracepoint!
> > 
> > 
> > static __printf(2, 3) int __dev_dbg(const struct device *dev, char *fmt, ...)
> > {
> > 	static char buf[DEV_DEBUG_PRINTK_SIZE];
> > 	unsigned long flags;
> > 	va_list ap;
> > 	int ret;
> > 
> > 	raw_spin_lock_irqsave(&dev_dbg_printk_lock, flags);
> > 	va_start(ap, fmt);
> > 	ret = vsnprintf(buf, sizeof(buf), fmt, ap);
> > 	va_end(ap);
> > 	/* vsnprintf() will not append null for zero-length strings */
> > 	if (ret == 0)
> > 		buf[0] = '\0';  
> 
> Wrong. snprintf(buf, 16, "") will work just fine and cause a '\0' to be
> written to buf[0]. As will snprintf(buf, 16, "%s", ""), and any other
> case where there ends up being no characters printed.

I just cut and pasted the bpf_trace_printk() code and modified it for here.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/trace/bpf_trace.c#n404


> 
> The only case where snprintf does not guarantee nul-termination is when
> the _buffer size_ is 0, in which case vsnprintf obviously cannot and
> must not write anything at all (that's used for the "how much do I need
> to allocate" situation).
> 
> > 
> > #define dev_dbg(dev, fmt, ...) 					\
> > 	do {							\
> > 		if (trace_dev_dbg_printk_enabled())		\
> > 			__dev_dbg(dev, fmt, ##__VA_ARGS__);	\
> > 	} while (0)
> > 
> > Note, the "trace_dev_dbg_printk_enabled()" is a static branch, which means
> > it is a nop when the dev_dbg_printk tracepoint is not enabled, and is a jmp
> > to the __dev_dbg() logic when it is enabled. It's not a conditional branch.  
> 
> dynamic_debug has been implemented in terms of static_keys for a long
> time. And that's a per-dev_dbg invocation static key. IIUC, the above
> would cause every single dev_dbg in the kernel to pass through the "grab
> a raw spin lock and do the snprintf" thing even when one is just
> interested in the dev_dbgs inside a single driver or function.

If you want to make it per device, I'm sure three's a way. Or allocate a
per-cpu buffer for the sprintf storage, and then you only need to disable
interrupts. And if you make the storage 4 levels deep per CPU (like
trace_printk does), then you only need to disable preemption and not even
interrupts.

The above wasn't a patch submission. It was a proof of concept. Everything
you brought up can be trivially dealt with.

-- Steve

  reply	other threads:[~2021-04-21 14:20 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-08 22:18 [PATCH][RFC] tracing: Enable tracepoints via module parameters Steven Rostedt
2011-03-08 22:42 ` Steven Rostedt
2011-03-08 23:22 ` Mathieu Desnoyers
2011-03-08 23:32   ` Steven Rostedt
2011-03-09  0:07     ` Mathieu Desnoyers
2011-03-09  0:14       ` Steven Rostedt
2011-03-09  0:29         ` Mathieu Desnoyers
2011-03-09  0:52           ` Steven Rostedt
2011-03-09  1:17             ` Mathieu Desnoyers
2011-03-09  2:01               ` Steven Rostedt
2011-03-09  2:30                 ` Mathieu Desnoyers
2011-03-09  2:01             ` Yuanhan Liu
2011-03-09  2:12               ` Steven Rostedt
2011-03-09  2:19                 ` Yuanhan Liu
2011-03-10 23:33 ` Rusty Russell
2013-08-13 15:14   ` Steven Rostedt
2013-08-13 22:34     ` Mathieu Desnoyers
2013-08-13 23:09       ` Steven Rostedt
2013-08-15  2:02     ` Rusty Russell
2013-08-15  3:32       ` Steven Rostedt
2021-04-19 21:54         ` Williams, Dan J
2021-04-19 22:11           ` Steven Rostedt
2021-04-20  1:25             ` Dan Williams
2021-04-20 12:55               ` Steven Rostedt
2021-04-20 13:29                 ` Mathieu Desnoyers
2021-04-20 14:55                   ` Steven Rostedt
2021-04-20 15:15                     ` Mathieu Desnoyers
2021-04-20 15:34                       ` Steven Rostedt
2021-04-20 19:54                 ` Dan Williams
2021-04-20 20:32                   ` Steven Rostedt
2021-04-21  6:27                     ` Dan Williams
2021-04-21  7:30                     ` Rasmus Villemoes
2021-04-21 14:20                       ` Steven Rostedt [this message]
2021-04-21 14:50                         ` Rasmus Villemoes
2021-04-21 15:00                           ` Steven Rostedt

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=20210421102008.411af7c5@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=dan.j.williams@intel.com \
    --cc=emmanuel.grumbach@intel.com \
    --cc=fweisbec@gmail.com \
    --cc=jeyu@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@elte.hu \
    --cc=yuanhan.liu@linux.intel.com \
    /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.