[PATCH] printk: Add printk_flush() to force buffered text to console

[PATCH] printk: Add printk_flush() to force buffered text to console

[Steven Rostedt]

Fengguang Wu had a config that caused the system to lockup. It reported:

[    6.086395] type=2000 audit(1339501575.085:1): initialized                                                                                                                       
[    6.116356] Kprobe smoke test started                                                                                                                                            
[    6.125915] Kprobe smoke test passed successfully                                                                                                                                
[    6.127478] rcu-torture:--- Start of test: nreaders=2 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0         
+fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4 shutdown_secs=0 onoff_interval=0 onoff_holdoff=0         

and then froze. So naturally, the suspected bug was with rcu-torture.
Fengguang did a git bisect and discovered that the crash came with a
function trace update. He also noticed that if he reverted that update,
the system got farther and showed:

[    1.611901] Testing tracer function: PASSED

His time was wasted by the fact that the function tracing self test
first prints:

  "Testing tracer function: "

then runs the test, and if it succeeds, it prints "PASSED", giving us
the nice output you see above.

But with the new printk() changes, text without a newline gets buffered
and does not print out to the console at the location of the printk.
This caused the "Testing tracer function: " not to print out and because
the test caused the kernel to lock up, we are clueless to the fact that
the problem was with the function tracer test and not the rcu_torture
test. As it made sense that the rcu_torture test could lock up the
system, many kernel developer hours were wasted chasing the wrong wild
goose.


If the "Testing tracer function: " had printed out in the first place,
we would have caught the correct wild goose and saved precious kernel
developer's time.

Thus a need for the following utility. That is to add a 'printk_flush()'
that acts like a fflush() in userspace to flush out the buffers used by
the printing facility so we don't have unexpected hunts for nature
roaming fowl.

I hooked onto the 'facility' infrastructure and used '8191' (the max
number) as the "flush" facility. I also added the use of '<f>' that is
only used internally to printk to distinguish a flush has been
requested.

I tested this out, (adding pr_flush() after my printk) and now the
lockup shows:

[    9.018231] Kprobe smoke test passed successfully
[    9.023084] rcu-torture:--- Start of test: nreaders=4 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_hold
off=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4 shutdown_secs=0 onoff_interval=0 onoff_holdoff=0
[    9.066065] Testing tracer function:


But now it adds a timestamp where one shouldn't be. But this isn't as
annoying as not having something print out when the system locks up. We
can figure out how to fix that later.

[    6.834073] Testing tracer function: [    7.136194] PASSED

Well, it shows the length of the test, so it isn't that bad.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 1bec2f7..b3317bf3 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -111,6 +111,8 @@ asmlinkage int printk_emit(int facility, int level,
 asmlinkage __printf(1, 2) __cold
 int printk(const char *fmt, ...);
 
+void printk_flush(void);
+
 /*
  * Special printk facility for scheduler use only, _DO_NOT_USE_ !
  */
@@ -158,6 +160,10 @@ static inline bool printk_timed_ratelimit(unsigned long *caller_jiffies,
 	return false;
 }
 
+static inline void printk_flush(void)
+{
+}
+
 static inline void log_buf_kexec_setup(void)
 {
 }
@@ -190,6 +196,8 @@ extern void dump_stack(void) __cold;
 	printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
 #define pr_cont(fmt, ...) \
 	printk(KERN_CONT fmt, ##__VA_ARGS__)
+#define pr_flush() \
+	printk_flush()
 
 /* pr_devel() should produce zero code unless DEBUG is defined */
 #ifdef DEBUG
diff --git a/kernel/printk.c b/kernel/printk.c
index 32462d2..dd27ac3 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -237,6 +237,9 @@ static char __log_buf[__LOG_BUF_LEN] __aligned(LOG_ALIGN);
 static char *log_buf = __log_buf;
 static u32 log_buf_len = __LOG_BUF_LEN;
 
+#define LOG_FLUSH	8191	/* 0xffff >> 3 */
+#define KERN_FLUSH	"<f>"
+
 /* cpu currently holding logbuf_lock */
 static volatile unsigned int logbuf_cpu = UINT_MAX;
 
@@ -843,7 +846,8 @@ static size_t msg_print_text(const struct log *msg, bool syslog,
 			len += print_prefix(msg, syslog, buf + len);
 			memcpy(buf + len, text, text_len);
 			len += text_len;
-			buf[len++] = '\n';
+			if (msg->level >> 3 != LOG_FLUSH)
+				buf[len++] = '\n';
 		} else {
 			/* SYSLOG_ACTION_* buffer size only calculation */
 			len += print_prefix(msg, syslog, NULL);
@@ -1275,6 +1279,7 @@ asmlinkage int vprintk_emit(int facility, int level,
 	int this_cpu;
 	bool newline = false;
 	bool prefix = false;
+	bool flush = false;
 	int printed_len = 0;
 
 	boot_delay_msec();
@@ -1339,18 +1344,29 @@ asmlinkage int vprintk_emit(int facility, int level,
 		case 'c':	/* KERN_CONT */
 			text += 3;
 			text_len -= 3;
+			break;
+		case 'f':	/* KERN_FLUSH - used internally */
+			flush = true;
 		}
 	}
 
-	if (level == -1)
-		level = default_message_loglevel;
+	if (!flush) {
+		if (level == -1)
+			level = default_message_loglevel;
 
-	if (dict) {
-		prefix = true;
-		newline = true;
+		if (dict) {
+			prefix = true;
+			newline = true;
+		}
 	}
 
-	if (!newline) {
+	if (flush) {
+		if (cont_len) {
+			log_store(LOG_FLUSH, cont_level, NULL, 0, cont_buf, cont_len);
+			cont_len = 0;
+		}
+
+	} else if (!newline) {
 		if (cont_len && (prefix || cont_task != current)) {
 			/*
 			 * Flush earlier buffer, which is either from a
@@ -1483,6 +1499,24 @@ asmlinkage int printk(const char *fmt, ...)
 }
 EXPORT_SYMBOL(printk);
 
+/**
+ * printk_flush - flush out any buffered text
+ *
+ * printk() will buffer text and not write it out to the console
+ * if the text was missing a newline. If it is required to get text
+ * out to the console without a newline, use printk_flush() and it
+ * will do that. This is useful when running self tests, where you
+ * have a line that prints what is being tested, and then if it
+ * passed or failed after the test, and you want this all done on
+ * a single line. Without flushing, if the test crashes, you may
+ * never see what was being tested.
+ */
+void printk_flush(void)
+{
+	printk("<f>");
+}
+EXPORT_SYMBOL(printk_flush);
+
 #else
 
 #define LOG_LINE_MAX 0

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Greg Kroah-Hartman]

On Thu, Jun 14, 2012 at 12:46:13AM -0400, Steven Rostedt wrote:
> Fengguang Wu had a config that caused the system to lockup. It reported:
> 
> [    6.086395] type=2000 audit(1339501575.085:1): initialized                                                                                                                       
> [    6.116356] Kprobe smoke test started                                                                                                                                            
> [    6.125915] Kprobe smoke test passed successfully                                                                                                                                
> [    6.127478] rcu-torture:--- Start of test: nreaders=2 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0         
> +fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4 shutdown_secs=0 onoff_interval=0 onoff_holdoff=0         
> 
> and then froze. So naturally, the suspected bug was with rcu-torture.
> Fengguang did a git bisect and discovered that the crash came with a
> function trace update. He also noticed that if he reverted that update,
> the system got farther and showed:
> 
> [    1.611901] Testing tracer function: PASSED
> 
> His time was wasted by the fact that the function tracing self test
> first prints:
> 
>   "Testing tracer function: "
> 
> then runs the test, and if it succeeds, it prints "PASSED", giving us
> the nice output you see above.

You can't do a simple:
	"Tracer function test starting"
	"Tracer function test succeeded"
instead?

What happens if other parts of the system are doing printk() calls?
Wouldn't it make more sense just to pair them up like this instead of
flushing (as you then end up with the timestamp messing things up like
you showed.)

Also, this way you know how long your tests take, which might be nice to
know to figure out where boot time is going :)

thanks,

greg k-h

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Steven Rostedt]

On Wed, 2012-06-13 at 21:59 -0700, Greg Kroah-Hartman wrote:
> On Thu, Jun 14, 2012 at 12:46:13AM -0400, Steven Rostedt wrote:
> > Fengguang Wu had a config that caused the system to lockup. It reported:
> > 
> > [    6.086395] type=2000 audit(1339501575.085:1): initialized                                                                                                                       
> > [    6.116356] Kprobe smoke test started                                                                                                                                            
> > [    6.125915] Kprobe smoke test passed successfully                                                                                                                                
> > [    6.127478] rcu-torture:--- Start of test: nreaders=2 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0         
> > +fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4 shutdown_secs=0 onoff_interval=0 onoff_holdoff=0         
> > 
> > and then froze. So naturally, the suspected bug was with rcu-torture.
> > Fengguang did a git bisect and discovered that the crash came with a
> > function trace update. He also noticed that if he reverted that update,
> > the system got farther and showed:
> > 
> > [    1.611901] Testing tracer function: PASSED
> > 
> > His time was wasted by the fact that the function tracing self test
> > first prints:
> > 
> >   "Testing tracer function: "
> > 
> > then runs the test, and if it succeeds, it prints "PASSED", giving us
> > the nice output you see above.
> 
> You can't do a simple:
> 	"Tracer function test starting"
> 	"Tracer function test succeeded"
> instead?

But I find that ugly ;-)


I know you can argue that the extra timestamp may be ugly too, but we
can work that out as well. I was just too tired to do so last night and
wanted to kick off the discussion before I got too tied up in other
things.

Currently we have something like this:

[    6.834073] Testing tracer function: [    7.136194] PASSED
[    7.567062] Testing dynamic ftrace: PASSED
[    8.053670] Testing dynamic ftrace ops #1: (1 0 1 1 0) (1 1 2 1 0) (2 1 3 1 18) (2 2 4 1 37) PASSED
[    8.566062] Testing dynamic ftrace ops #2: (1 0 1 7 0) (1 1 2 38 0) (2 1 3 1 6) (2 2 4 36 36) PASSED
[    8.596063] Testing tracer irqsoff: [    9.014064] PASSED
[    9.038062] Testing tracer wakeup: [    9.681063] PASSED
[    9.705066] Testing tracer wakeup_rt: [   10.347064] PASSED
[   10.371063] Testing tracer function_graph: [   10.876064] PASSED

I didn't fix the dynamic ftrace ops #1 and #2 to flush, but that should
too, as each set of (1 0 1 1 0) etc, numbers are important, and is a
separate test. That could lock up the system as well and knowing where
it locked up is key to debugging.

To make this work with the current printk, I have to do:

Tracer function test started
Tracer function test succeeded
Tracer dynamic ftrace test started
Tracer dynamic ftrace test succeeded
Tracer dynamic ftrace ops #1 test started
(1 0 1 1 0)
(1 1 2 1 0)
(2 1 3 1 18)
(2 2 4 1 37)
Tracer dynamic ftrace ops #1 test succeeded
Tracer dynamic ftrace ops #2 test started
(1 0 1 7 0)
(1 1 2 38 0)
(2 1 3 1 6)
(2 2 4 36 36)
Tracer dynamic ftrace ops #2 succeeded
Tracer irqsoff test started
Tracer irqsoff test succeeded
Tracer wakeup test started
Tracer wakeup test succeeded
Tracer wakeup_rt test started
Tracer wakeup_rt test succeeded
Tracer function_graph test started
Tracer function_graph test succeeded


Yes, this would give us the functionality of today but more lines of
text on the output line. Then we have to worry about the trace event
tests:


[   72.177731] Testing event rpc_bind_status: OK
[   72.187100] Testing event rpc_connect_status: OK
[   72.196501] Testing event rpc_task_begin: OK
[   72.205504] Testing event rpc_task_run_action: OK
[   72.214487] Testing event rpc_task_complete: OK
[   72.223504] Testing event rpc_task_sleep: OK
[   72.232500] Testing event rpc_task_wakeup: OK
[   72.241504] Testing event kfree_skb: OK
[   72.249486] Testing event consume_skb: OK
[   72.257504] Testing event skb_copy_datagram_iovec: OK
[   72.267500] Testing event net_dev_xmit: OK
[   72.276486] Testing event net_dev_queue: OK
[   72.285504] Testing event netif_receive_skb: OK
[   72.294486] Testing event netif_rx: OK
[   72.302504] Testing event napi_poll: OK
[   72.310486] Testing event sock_rcvqueue_full: OK
[   72.319504] Testing event sock_exceed_buf_limit: OK
[   72.328486] Testing event udp_fail_queue_rcv_skb: OK
[   72.337503] Testing event hda_send_cmd: OK
[   72.346501] Testing event hda_get_response: OK
[   72.355503] Testing event hda_bus_reset: OK
[   72.364501] Testing event hda_power_down: OK
[   72.373503] Testing event hda_power_up: OK
[   72.382500] Testing event hda_unsol_event: OK
[   72.391504] Testing event scsi_dispatch_cmd_start: OK
[   72.401501] Testing event scsi_dispatch_cmd_error: OK
[   72.411487] Testing event scsi_dispatch_cmd_done: OK
[   72.420503] Testing event scsi_dispatch_cmd_timeout: OK
[   72.430501] Testing event scsi_eh_wakeup: OK
[   72.439505] Testing event i915_gem_object_create: OK
[   72.448486] Testing event i915_gem_object_bind: OK
[   72.457504] Testing event i915_gem_object_unbind: OK
[   72.466487] Testing event i915_gem_object_change_domain: OK
[   72.476504] Testing event i915_gem_object_pwrite: OK
[   72.485486] Testing event i915_gem_object_pread: OK
[   72.494504] Testing event i915_gem_object_fault: OK
[   72.503485] Testing event i915_gem_object_clflush: OK
[   72.513488] Testing event i915_gem_object_destroy: OK
[   72.523488] Testing event i915_gem_evict: OK
[   72.532479] Testing event i915_gem_evict_everything: OK
[   72.542505] Testing event i915_gem_ring_dispatch: OK
[   72.551486] Testing event i915_gem_ring_flush: OK
[   72.560478] Testing event i915_gem_request_add: OK
[   72.569506] Testing event i915_gem_request_complete: OK
[   72.579501] Testing event i915_gem_request_retire: OK
[   72.589485] Testing event i915_gem_request_wait_begin: OK
[   72.599506] Testing event i915_gem_request_wait_end: OK
[   72.609501] Testing event i915_ring_wait_begin: OK
[   72.618504] Testing event i915_ring_wait_end: OK
[   72.627488] Testing event i915_flip_request: OK
[...]

This does it for every event that is created. This case had 1556 events
tested.

The config had:

CONFIG_FTRACE_SELFTEST=y
CONFIG_FTRACE_STARTUP_TEST=y
# CONFIG_EVENT_TRACE_TEST_SYSCALLS is not set

If CONFIG_EVENT_TRACE_TEST_SYSCALLS is set, then it does the testing of
every system call entry and exit event.

> 
> What happens if other parts of the system are doing printk() calls?
> Wouldn't it make more sense just to pair them up like this instead of
> flushing (as you then end up with the timestamp messing things up like
> you showed.)

On system boot up there's not much that gets interrupted. And yeah, I
don't like the timestamp in the middle. But that just means we need to
work to fix that too ;-)

> 
> Also, this way you know how long your tests take, which might be nice to
> know to figure out where boot time is going :)

Hehe, if you have self tests enabled, you can bet the boot time is going
to them. I have no intention on speeding the tests up, if anything, I
want to add more to them, which would slow them down.

If you are concerned about boot up (and for production environments) you
do not enable these self tests. That wasn't their purpose. They were
created for developers to test their systems, just like lockdep and
kmemcheck are. You don't want those running on your production
environment either.

-- Steve

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Greg Kroah-Hartman]

On Thu, Jun 14, 2012 at 07:01:55AM -0400, Steven Rostedt wrote:
> On Wed, 2012-06-13 at 21:59 -0700, Greg Kroah-Hartman wrote:
> > On Thu, Jun 14, 2012 at 12:46:13AM -0400, Steven Rostedt wrote:
> > > Fengguang Wu had a config that caused the system to lockup. It reported:
> > > 
> > > [    6.086395] type=2000 audit(1339501575.085:1): initialized                                                                                                                       
> > > [    6.116356] Kprobe smoke test started                                                                                                                                            
> > > [    6.125915] Kprobe smoke test passed successfully                                                                                                                                
> > > [    6.127478] rcu-torture:--- Start of test: nreaders=2 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0         
> > > +fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4 shutdown_secs=0 onoff_interval=0 onoff_holdoff=0         
> > > 
> > > and then froze. So naturally, the suspected bug was with rcu-torture.
> > > Fengguang did a git bisect and discovered that the crash came with a
> > > function trace update. He also noticed that if he reverted that update,
> > > the system got farther and showed:
> > > 
> > > [    1.611901] Testing tracer function: PASSED
> > > 
> > > His time was wasted by the fact that the function tracing self test
> > > first prints:
> > > 
> > >   "Testing tracer function: "
> > > 
> > > then runs the test, and if it succeeds, it prints "PASSED", giving us
> > > the nice output you see above.
> > 
> > You can't do a simple:
> > 	"Tracer function test starting"
> > 	"Tracer function test succeeded"
> > instead?
> 
> But I find that ugly ;-)

I find printk_flush() ugly :)

> I know you can argue that the extra timestamp may be ugly too, but we
> can work that out as well. I was just too tired to do so last night and
> wanted to kick off the discussion before I got too tied up in other
> things.
> 
> Currently we have something like this:
> 
> [    6.834073] Testing tracer function: [    7.136194] PASSED
> [    7.567062] Testing dynamic ftrace: PASSED
> [    8.053670] Testing dynamic ftrace ops #1: (1 0 1 1 0) (1 1 2 1 0) (2 1 3 1 18) (2 2 4 1 37) PASSED
> [    8.566062] Testing dynamic ftrace ops #2: (1 0 1 7 0) (1 1 2 38 0) (2 1 3 1 6) (2 2 4 36 36) PASSED

That's ugly to me :)

> [    8.596063] Testing tracer irqsoff: [    9.014064] PASSED
> [    9.038062] Testing tracer wakeup: [    9.681063] PASSED
> [    9.705066] Testing tracer wakeup_rt: [   10.347064] PASSED
> [   10.371063] Testing tracer function_graph: [   10.876064] PASSED
> 
> I didn't fix the dynamic ftrace ops #1 and #2 to flush, but that should
> too, as each set of (1 0 1 1 0) etc, numbers are important, and is a
> separate test. That could lock up the system as well and knowing where
> it locked up is key to debugging.
> 
> To make this work with the current printk, I have to do:
> 
> Tracer function test started
> Tracer function test succeeded
> Tracer dynamic ftrace test started
> Tracer dynamic ftrace test succeeded
> Tracer dynamic ftrace ops #1 test started
> (1 0 1 1 0)
> (1 1 2 1 0)
> (2 1 3 1 18)
> (2 2 4 1 37)

I suggest better prefixes here.

> Tracer dynamic ftrace ops #1 test succeeded
> Tracer dynamic ftrace ops #2 test started
> (1 0 1 7 0)
> (1 1 2 38 0)
> (2 1 3 1 6)
> (2 2 4 36 36)

And here.

> Tracer dynamic ftrace ops #2 succeeded
> Tracer irqsoff test started
> Tracer irqsoff test succeeded
> Tracer wakeup test started
> Tracer wakeup test succeeded
> Tracer wakeup_rt test started
> Tracer wakeup_rt test succeeded
> Tracer function_graph test started
> Tracer function_graph test succeeded
> 
> 
> Yes, this would give us the functionality of today but more lines of
> text on the output line. Then we have to worry about the trace event
> tests:

So what?  You are doing development tests, it's ok to print out a lot of
messages, that is what you want to see, especially when something fails,
right?

> [   72.177731] Testing event rpc_bind_status: OK
> [   72.187100] Testing event rpc_connect_status: OK
> [   72.196501] Testing event rpc_task_begin: OK
> [   72.205504] Testing event rpc_task_run_action: OK
> [   72.214487] Testing event rpc_task_complete: OK
> [   72.223504] Testing event rpc_task_sleep: OK
> [   72.232500] Testing event rpc_task_wakeup: OK
> [   72.241504] Testing event kfree_skb: OK
> [   72.249486] Testing event consume_skb: OK
> [   72.257504] Testing event skb_copy_datagram_iovec: OK
> [   72.267500] Testing event net_dev_xmit: OK
> [   72.276486] Testing event net_dev_queue: OK
> [   72.285504] Testing event netif_receive_skb: OK
> [   72.294486] Testing event netif_rx: OK
> [   72.302504] Testing event napi_poll: OK
> [   72.310486] Testing event sock_rcvqueue_full: OK
> [   72.319504] Testing event sock_exceed_buf_limit: OK
> [   72.328486] Testing event udp_fail_queue_rcv_skb: OK
> [   72.337503] Testing event hda_send_cmd: OK
> [   72.346501] Testing event hda_get_response: OK
> [   72.355503] Testing event hda_bus_reset: OK
> [   72.364501] Testing event hda_power_down: OK
> [   72.373503] Testing event hda_power_up: OK
> [   72.382500] Testing event hda_unsol_event: OK
> [   72.391504] Testing event scsi_dispatch_cmd_start: OK
> [   72.401501] Testing event scsi_dispatch_cmd_error: OK
> [   72.411487] Testing event scsi_dispatch_cmd_done: OK
> [   72.420503] Testing event scsi_dispatch_cmd_timeout: OK
> [   72.430501] Testing event scsi_eh_wakeup: OK
> [   72.439505] Testing event i915_gem_object_create: OK
> [   72.448486] Testing event i915_gem_object_bind: OK
> [   72.457504] Testing event i915_gem_object_unbind: OK
> [   72.466487] Testing event i915_gem_object_change_domain: OK
> [   72.476504] Testing event i915_gem_object_pwrite: OK
> [   72.485486] Testing event i915_gem_object_pread: OK
> [   72.494504] Testing event i915_gem_object_fault: OK
> [   72.503485] Testing event i915_gem_object_clflush: OK
> [   72.513488] Testing event i915_gem_object_destroy: OK
> [   72.523488] Testing event i915_gem_evict: OK
> [   72.532479] Testing event i915_gem_evict_everything: OK
> [   72.542505] Testing event i915_gem_ring_dispatch: OK
> [   72.551486] Testing event i915_gem_ring_flush: OK
> [   72.560478] Testing event i915_gem_request_add: OK
> [   72.569506] Testing event i915_gem_request_complete: OK
> [   72.579501] Testing event i915_gem_request_retire: OK
> [   72.589485] Testing event i915_gem_request_wait_begin: OK
> [   72.599506] Testing event i915_gem_request_wait_end: OK
> [   72.609501] Testing event i915_ring_wait_begin: OK
> [   72.618504] Testing event i915_ring_wait_end: OK
> [   72.627488] Testing event i915_flip_request: OK
> [...]
> 
> This does it for every event that is created. This case had 1556 events
> tested.

Great, lots of messages, be sure to increment your printk buffer size.
Or write saner tests :)

> The config had:
> 
> CONFIG_FTRACE_SELFTEST=y
> CONFIG_FTRACE_STARTUP_TEST=y
> # CONFIG_EVENT_TRACE_TEST_SYSCALLS is not set
> 
> If CONFIG_EVENT_TRACE_TEST_SYSCALLS is set, then it does the testing of
> every system call entry and exit event.

Ok, but then again, that's your choice to do so, no "sane" person
normally enables that option...

> > What happens if other parts of the system are doing printk() calls?
> > Wouldn't it make more sense just to pair them up like this instead of
> > flushing (as you then end up with the timestamp messing things up like
> > you showed.)
> 
> On system boot up there's not much that gets interrupted. And yeah, I
> don't like the timestamp in the middle. But that just means we need to
> work to fix that too ;-)

I think with a few minor changes as mentioned above, your messages will
look just fine, and you will know better how long things take, and what
exactly fails, which is what you want to know, right?

> > Also, this way you know how long your tests take, which might be nice to
> > know to figure out where boot time is going :)
> 
> Hehe, if you have self tests enabled, you can bet the boot time is going
> to them. I have no intention on speeding the tests up, if anything, I
> want to add more to them, which would slow them down.
> 
> If you are concerned about boot up (and for production environments) you
> do not enable these self tests. That wasn't their purpose. They were
> created for developers to test their systems, just like lockdep and
> kmemcheck are. You don't want those running on your production
> environment either.

Ok, then you just answered your own question there, make the messages a
bit "prettier" and all is fine, as no one will ever use this in
production, only for developers, and we can handle the little bit extra
printk noise, at the expense of providing accurate information.

thanks,

greg k-h

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Steven Rostedt]

On Thu, 2012-06-14 at 08:41 -0700, Greg Kroah-Hartman wrote:
>  
> > But I find that ugly ;-)
> 
> I find printk_flush() ugly :)
> 

I guess beauty is really in the eye of the beholder.

> > I know you can argue that the extra timestamp may be ugly too, but we
> > can work that out as well. I was just too tired to do so last night and
> > wanted to kick off the discussion before I got too tied up in other
> > things.
> > 
> > Currently we have something like this:
> > 
> > [    6.834073] Testing tracer function: [    7.136194] PASSED
> > [    7.567062] Testing dynamic ftrace: PASSED
> > [    8.053670] Testing dynamic ftrace ops #1: (1 0 1 1 0) (1 1 2 1 0) (2 1 3 1 18) (2 2 4 1 37) PASSED
> > [    8.566062] Testing dynamic ftrace ops #2: (1 0 1 7 0) (1 1 2 38 0) (2 1 3 1 6) (2 2 4 36 36) PASSED
> 
> That's ugly to me :)

No no, that's pretty to you. Maybe meaningless, but pretty!

> 
> > [    8.596063] Testing tracer irqsoff: [    9.014064] PASSED
> > [    9.038062] Testing tracer wakeup: [    9.681063] PASSED
> > [    9.705066] Testing tracer wakeup_rt: [   10.347064] PASSED
> > [   10.371063] Testing tracer function_graph: [   10.876064] PASSED
> > 
> > I didn't fix the dynamic ftrace ops #1 and #2 to flush, but that should
> > too, as each set of (1 0 1 1 0) etc, numbers are important, and is a
> > separate test. That could lock up the system as well and knowing where
> > it locked up is key to debugging.
> > 
> > To make this work with the current printk, I have to do:
> > 
> > Tracer function test started
> > Tracer function test succeeded
> > Tracer dynamic ftrace test started
> > Tracer dynamic ftrace test succeeded
> > Tracer dynamic ftrace ops #1 test started
> > (1 0 1 1 0)
> > (1 1 2 1 0)
> > (2 1 3 1 18)
> > (2 2 4 1 37)
> 
> I suggest better prefixes here.

And let people in on my secret (well, without having to read the
code) ;-)

> 
> > Tracer dynamic ftrace ops #1 test succeeded
> > Tracer dynamic ftrace ops #2 test started
> > (1 0 1 7 0)
> > (1 1 2 38 0)
> > (2 1 3 1 6)
> > (2 2 4 36 36)
> 
> And here.
> 
> > Tracer dynamic ftrace ops #2 succeeded
> > Tracer irqsoff test started
> > Tracer irqsoff test succeeded
> > Tracer wakeup test started
> > Tracer wakeup test succeeded
> > Tracer wakeup_rt test started
> > Tracer wakeup_rt test succeeded
> > Tracer function_graph test started
> > Tracer function_graph test succeeded
> > 
> > 
> > Yes, this would give us the functionality of today but more lines of
> > text on the output line. Then we have to worry about the trace event
> > tests:
> 
> So what?  You are doing development tests, it's ok to print out a lot of
> messages, that is what you want to see, especially when something fails,
> right?

I actually would like to make these more compact. As all my test box
consoles go through serial ports, just booting through this takes more
time the the compile itself.

> 
> > [   72.177731] Testing event rpc_bind_status: OK
> > [   72.187100] Testing event rpc_connect_status: OK
> > [   72.196501] Testing event rpc_task_begin: OK
> > [   72.205504] Testing event rpc_task_run_action: OK
> > [   72.214487] Testing event rpc_task_complete: OK
> > [   72.223504] Testing event rpc_task_sleep: OK
> > [   72.232500] Testing event rpc_task_wakeup: OK
> > [   72.241504] Testing event kfree_skb: OK
> > [   72.249486] Testing event consume_skb: OK
> > [   72.257504] Testing event skb_copy_datagram_iovec: OK
> > [   72.267500] Testing event net_dev_xmit: OK
> > [   72.276486] Testing event net_dev_queue: OK
> > [   72.285504] Testing event netif_receive_skb: OK
> > [   72.294486] Testing event netif_rx: OK
> > [   72.302504] Testing event napi_poll: OK
> > [   72.310486] Testing event sock_rcvqueue_full: OK
> > [   72.319504] Testing event sock_exceed_buf_limit: OK
> > [   72.328486] Testing event udp_fail_queue_rcv_skb: OK
> > [   72.337503] Testing event hda_send_cmd: OK
> > [   72.346501] Testing event hda_get_response: OK
> > [   72.355503] Testing event hda_bus_reset: OK
> > [   72.364501] Testing event hda_power_down: OK
> > [   72.373503] Testing event hda_power_up: OK
> > [   72.382500] Testing event hda_unsol_event: OK
> > [   72.391504] Testing event scsi_dispatch_cmd_start: OK
> > [   72.401501] Testing event scsi_dispatch_cmd_error: OK
> > [   72.411487] Testing event scsi_dispatch_cmd_done: OK
> > [   72.420503] Testing event scsi_dispatch_cmd_timeout: OK
> > [   72.430501] Testing event scsi_eh_wakeup: OK
> > [   72.439505] Testing event i915_gem_object_create: OK
> > [   72.448486] Testing event i915_gem_object_bind: OK
> > [   72.457504] Testing event i915_gem_object_unbind: OK
> > [   72.466487] Testing event i915_gem_object_change_domain: OK
> > [   72.476504] Testing event i915_gem_object_pwrite: OK
> > [   72.485486] Testing event i915_gem_object_pread: OK
> > [   72.494504] Testing event i915_gem_object_fault: OK
> > [   72.503485] Testing event i915_gem_object_clflush: OK
> > [   72.513488] Testing event i915_gem_object_destroy: OK
> > [   72.523488] Testing event i915_gem_evict: OK
> > [   72.532479] Testing event i915_gem_evict_everything: OK
> > [   72.542505] Testing event i915_gem_ring_dispatch: OK
> > [   72.551486] Testing event i915_gem_ring_flush: OK
> > [   72.560478] Testing event i915_gem_request_add: OK
> > [   72.569506] Testing event i915_gem_request_complete: OK
> > [   72.579501] Testing event i915_gem_request_retire: OK
> > [   72.589485] Testing event i915_gem_request_wait_begin: OK
> > [   72.599506] Testing event i915_gem_request_wait_end: OK
> > [   72.609501] Testing event i915_ring_wait_begin: OK
> > [   72.618504] Testing event i915_ring_wait_end: OK
> > [   72.627488] Testing event i915_flip_request: OK
> > [...]
> > 
> > This does it for every event that is created. This case had 1556 events
> > tested.
> 
> Great, lots of messages, be sure to increment your printk buffer size.
> Or write saner tests :)

No reason for extended buffer size, this is all recorded on serial
console.

> 
> > The config had:
> > 
> > CONFIG_FTRACE_SELFTEST=y
> > CONFIG_FTRACE_STARTUP_TEST=y
> > # CONFIG_EVENT_TRACE_TEST_SYSCALLS is not set
> > 
> > If CONFIG_EVENT_TRACE_TEST_SYSCALLS is set, then it does the testing of
> > every system call entry and exit event.
> 
> Ok, but then again, that's your choice to do so, no "sane" person
> normally enables that option...

No "sane" person would enable any of the above options. They are for
testing purposes only. This of course assumes that kernel developers are
not "sane".


> 
> > > What happens if other parts of the system are doing printk() calls?
> > > Wouldn't it make more sense just to pair them up like this instead of
> > > flushing (as you then end up with the timestamp messing things up like
> > > you showed.)
> > 
> > On system boot up there's not much that gets interrupted. And yeah, I
> > don't like the timestamp in the middle. But that just means we need to
> > work to fix that too ;-)
> 
> I think with a few minor changes as mentioned above, your messages will
> look just fine, and you will know better how long things take,

I've never really worried about how long, as the output of the message
itself takes up more time than most of those tests.

>  and what
> exactly fails, which is what you want to know, right?

Well, it did that before the updated printk() code.

> 
> > > Also, this way you know how long your tests take, which might be nice to
> > > know to figure out where boot time is going :)
> > 
> > Hehe, if you have self tests enabled, you can bet the boot time is going
> > to them. I have no intention on speeding the tests up, if anything, I
> > want to add more to them, which would slow them down.
> > 
> > If you are concerned about boot up (and for production environments) you
> > do not enable these self tests. That wasn't their purpose. They were
> > created for developers to test their systems, just like lockdep and
> > kmemcheck are. You don't want those running on your production
> > environment either.
> 
> Ok, then you just answered your own question there, make the messages a
> bit "prettier" and all is fine, as no one will ever use this in
> production, only for developers, and we can handle the little bit extra
> printk noise, at the expense of providing accurate information.

That accurate information is there with the original printk(), but is
broken with the new method.

Currently, I have a patch to force printk() to become early_printk()
that I'll be using for the time being. Until it bothers me enough (read,
user reports are messed up), will this get fixed.

-- Steve

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Fengguang Wu]

> I actually would like to make these more compact. As all my test box
> consoles go through serial ports, just booting through this takes more
> time the the compile itself.

The tests took 23 seconds boot time on one kernel:

        [    0.152934] Testing tracer nop: PASSED
        ...1577 lines total...
        [   23.206550] Testing kprobe tracing: OK

And 135 seconds in another bloated kernel:

        [  115.396441] Testing event 9p_client_req: OK
        ...2545 lines total...
        [  240.268783] Testing kprobe tracing: OK

I'd appreciate if the boot time can be reduced. Because I'm doing
kernel boot tests for *every single* commits.

It may look insane amount of work, but it's still manageable: with 10
kvm instances each take 1 minute to boot test a kernel, I can boot
test 60*24*10=14400 kernels in one day. That's a rather big number.
That allows me to run more cpu/vm/io stress tests for each kernel :-)

Thanks,
Fengguang

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Greg Kroah-Hartman]

On Fri, Jun 15, 2012 at 12:22:33PM +0800, Fengguang Wu wrote:
> > I actually would like to make these more compact. As all my test box
> > consoles go through serial ports, just booting through this takes more
> > time the the compile itself.
> 
> The tests took 23 seconds boot time on one kernel:
> 
>         [    0.152934] Testing tracer nop: PASSED
>         ...1577 lines total...
>         [   23.206550] Testing kprobe tracing: OK
> 
> And 135 seconds in another bloated kernel:
> 
>         [  115.396441] Testing event 9p_client_req: OK
>         ...2545 lines total...
>         [  240.268783] Testing kprobe tracing: OK
> 
> I'd appreciate if the boot time can be reduced. Because I'm doing
> kernel boot tests for *every single* commits.
> 
> It may look insane amount of work, but it's still manageable: with 10
> kvm instances each take 1 minute to boot test a kernel, I can boot
> test 60*24*10=14400 kernels in one day. That's a rather big number.
> That allows me to run more cpu/vm/io stress tests for each kernel :-)

Do you really want to enable those tests for your test kernels?  Can
they fail if we mess up other parts of the kernel, or do they only test
the tracing portions?

greg k-h

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Fengguang Wu]

On Thu, Jun 14, 2012 at 09:30:17PM -0700, Greg Kroah-Hartman wrote:
> On Fri, Jun 15, 2012 at 12:22:33PM +0800, Fengguang Wu wrote:
> > > I actually would like to make these more compact. As all my test box
> > > consoles go through serial ports, just booting through this takes more
> > > time the the compile itself.
> > 
> > The tests took 23 seconds boot time on one kernel:
> > 
> >         [    0.152934] Testing tracer nop: PASSED
> >         ...1577 lines total...
> >         [   23.206550] Testing kprobe tracing: OK
> > 
> > And 135 seconds in another bloated kernel:
> > 
> >         [  115.396441] Testing event 9p_client_req: OK
> >         ...2545 lines total...
> >         [  240.268783] Testing kprobe tracing: OK
> > 
> > I'd appreciate if the boot time can be reduced. Because I'm doing
> > kernel boot tests for *every single* commits.
> > 
> > It may look insane amount of work, but it's still manageable: with 10
> > kvm instances each take 1 minute to boot test a kernel, I can boot
> > test 60*24*10=14400 kernels in one day. That's a rather big number.
> > That allows me to run more cpu/vm/io stress tests for each kernel :-)
> 
> Do you really want to enable those tests for your test kernels?  Can
> they fail if we mess up other parts of the kernel, or do they only test
> the tracing portions?

Good question. If the tests are only relevant to the tracing system,
it's better to enable them only when testing the tracing commits. Just
like I won't run ext4 tests for an XFS commit.

Thanks,
Fengguang

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Ingo Molnar]

* Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Fri, Jun 15, 2012 at 12:22:33PM +0800, Fengguang Wu wrote:
> > > I actually would like to make these more compact. As all my test box
> > > consoles go through serial ports, just booting through this takes more
> > > time the the compile itself.
> > 
> > The tests took 23 seconds boot time on one kernel:
> > 
> >         [    0.152934] Testing tracer nop: PASSED
> >         ...1577 lines total...
> >         [   23.206550] Testing kprobe tracing: OK
> > 
> > And 135 seconds in another bloated kernel:
> > 
> >         [  115.396441] Testing event 9p_client_req: OK
> >         ...2545 lines total...
> >         [  240.268783] Testing kprobe tracing: OK
> > 
> > I'd appreciate if the boot time can be reduced. Because I'm doing
> > kernel boot tests for *every single* commits.
> > 
> > It may look insane amount of work, but it's still manageable: with 10
> > kvm instances each take 1 minute to boot test a kernel, I can boot
> > test 60*24*10=14400 kernels in one day. That's a rather big number.
> > That allows me to run more cpu/vm/io stress tests for each kernel :-)
> 
> Do you really want to enable those tests for your test 
> kernels?  Can they fail if we mess up other parts of the 
> kernel, or do they only test the tracing portions?

These printk's are useful, are used for a specific (albeit 
limited) purpose and were and continue to be useful in that 
role.

The changes Steve bisected to broke this use of printk(). Please 
apply Steve's fix, fix it yourself or revert the changes that 
regressed printk().

Thanks,

	Ingo

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Greg Kroah-Hartman]

On Fri, Jun 15, 2012 at 02:04:30PM +0200, Ingo Molnar wrote:
> 
> * Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> 
> > On Fri, Jun 15, 2012 at 12:22:33PM +0800, Fengguang Wu wrote:
> > > > I actually would like to make these more compact. As all my test box
> > > > consoles go through serial ports, just booting through this takes more
> > > > time the the compile itself.
> > > 
> > > The tests took 23 seconds boot time on one kernel:
> > > 
> > >         [    0.152934] Testing tracer nop: PASSED
> > >         ...1577 lines total...
> > >         [   23.206550] Testing kprobe tracing: OK
> > > 
> > > And 135 seconds in another bloated kernel:
> > > 
> > >         [  115.396441] Testing event 9p_client_req: OK
> > >         ...2545 lines total...
> > >         [  240.268783] Testing kprobe tracing: OK
> > > 
> > > I'd appreciate if the boot time can be reduced. Because I'm doing
> > > kernel boot tests for *every single* commits.
> > > 
> > > It may look insane amount of work, but it's still manageable: with 10
> > > kvm instances each take 1 minute to boot test a kernel, I can boot
> > > test 60*24*10=14400 kernels in one day. That's a rather big number.
> > > That allows me to run more cpu/vm/io stress tests for each kernel :-)
> > 
> > Do you really want to enable those tests for your test 
> > kernels?  Can they fail if we mess up other parts of the 
> > kernel, or do they only test the tracing portions?
> 
> These printk's are useful, are used for a specific (albeit 
> limited) purpose and were and continue to be useful in that 
> role.
> 
> The changes Steve bisected to broke this use of printk().

And note, fixed others :)

> Please apply Steve's fix, fix it yourself or revert the changes that
> regressed printk().

I thought Steve's patch was just a RFC thing, is it really something
that everyone wants to see applied?

thanks,

greg k-h

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Steven Rostedt]

On Fri, 2012-06-15 at 16:13 -0700, Greg Kroah-Hartman wrote:

> > Please apply Steve's fix, fix it yourself or revert the changes that
> > regressed printk().
> 
> I thought Steve's patch was just a RFC thing, is it really something
> that everyone wants to see applied?

It was, and still is, an RFC. I'd like to fix the double printing of the
time stamps as well.

It was really a compromise, as the new printk() is a serious
functionality change. Even though I mostly use trace_printk(), there are
still times that I like to use printk in some hot spots. For example I
sometimes to do:

printk("a");
some_code();
printk("b");
more_code();
printk("c");
continued_code();
[etc]


And watch a stream of 'abcabcabc...' and see where finally something
causes the machine to triple fault and reboot.

Because the bug would cause a triple fault, there would be no time to
recover data from trace_printk(). But as the code is quite hot, my use
of printk is to be as small as possible and with no new lines.

But now this method is gone. Not to mention, digging through the complex
maze of the new printk, I realize that it's not optimize for speed at
all. But printing to the serial console makes it not that big of a deal.

I have patches that just force printk() to be early_printk(), and in
fact, we have in the -rt patch this:

http://git.kernel.org/?p=linux/kernel/git/rt/linux-stable-rt.git;a=blobdiff;f=kernel/printk.c;h=5a172f9e5027b7416a82e54dfc29afbda71296ee;hp=c4426061e228c252e226feb67193d80cdba3af5b;hb=865407ef06e61c97cdd9091082ed8038c801f535;hpb=c09d1c02743a7d2df13574d93dea9f21ccf02560

I had my own patch that did pretty much the same thing, and I was very
happy to see that Ingo had the same mind set.

Actually, I think that patch really should go mainline, and give others
some of the luxury that us -rt folks enjoy.

But back to this patch. I was irritated that we blamed the wrong code
because the printk functionality changed. And instead of writing some
drastic changes that would be controversial, I suggested a
'printk_flush()' that would work similar to a fflush(). Yeah, buffering
is good and lets lines fit together, but there's times where getting the
partial line out to the screen is more important that keeping it
together.

If other printks were interleaved and it didn't crash, we wouldn't care
(or even notice). But if it did crash, I'll even argue seeing the
interleaved printks would provide a hint to why it crashed.

-- Steve

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Greg Kroah-Hartman]

On Fri, Jun 15, 2012 at 07:53:35PM -0400, Steven Rostedt wrote:
> On Fri, 2012-06-15 at 16:13 -0700, Greg Kroah-Hartman wrote:
> 
> > > Please apply Steve's fix, fix it yourself or revert the changes that
> > > regressed printk().
> > 
> > I thought Steve's patch was just a RFC thing, is it really something
> > that everyone wants to see applied?
> 
> It was, and still is, an RFC. I'd like to fix the double printing of the
> time stamps as well.
> 
> It was really a compromise, as the new printk() is a serious
> functionality change. Even though I mostly use trace_printk(), there are
> still times that I like to use printk in some hot spots. For example I
> sometimes to do:
> 
> printk("a");
> some_code();
> printk("b");
> more_code();
> printk("c");
> continued_code();
> [etc]
> 
> 
> And watch a stream of 'abcabcabc...' and see where finally something
> causes the machine to triple fault and reboot.

Yeah, that's not good, but note that because of this change, other
things that were failing are now working properly, we really can't have
one without the other here :(

> Because the bug would cause a triple fault, there would be no time to
> recover data from trace_printk(). But as the code is quite hot, my use
> of printk is to be as small as possible and with no new lines.
> 
> But now this method is gone. Not to mention, digging through the complex
> maze of the new printk, I realize that it's not optimize for speed at
> all. But printing to the serial console makes it not that big of a deal.
> 
> I have patches that just force printk() to be early_printk(), and in
> fact, we have in the -rt patch this:
> 
> http://git.kernel.org/?p=linux/kernel/git/rt/linux-stable-rt.git;a=blobdiff;f=kernel/printk.c;h=5a172f9e5027b7416a82e54dfc29afbda71296ee;hp=c4426061e228c252e226feb67193d80cdba3af5b;hb=865407ef06e61c97cdd9091082ed8038c801f535;hpb=c09d1c02743a7d2df13574d93dea9f21ccf02560
> 
> I had my own patch that did pretty much the same thing, and I was very
> happy to see that Ingo had the same mind set.
> 
> Actually, I think that patch really should go mainline, and give others
> some of the luxury that us -rt folks enjoy.

That would be good.

> But back to this patch. I was irritated that we blamed the wrong code
> because the printk functionality changed. And instead of writing some
> drastic changes that would be controversial, I suggested a
> 'printk_flush()' that would work similar to a fflush(). Yeah, buffering
> is good and lets lines fit together, but there's times where getting the
> partial line out to the screen is more important that keeping it
> together.

I agree, it's frustrating to go down the wrong path, sorry about that.

> If other printks were interleaved and it didn't crash, we wouldn't care
> (or even notice). But if it did crash, I'll even argue seeing the
> interleaved printks would provide a hint to why it crashed.

Ok, so what do you want to do here?  Fix up your RFC patch to not have
the printk stamps?  Or something like the above rt patch?

thanks,

greg k-h

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Steven Rostedt]

On Mon, 2012-06-18 at 16:03 -0700, Greg Kroah-Hartman wrote:

> > Actually, I think that patch really should go mainline, and give others
> > some of the luxury that us -rt folks enjoy.
> 
> That would be good.

Maybe I'll package that up if Ingo has no objections.


> > If other printks were interleaved and it didn't crash, we wouldn't care
> > (or even notice). But if it did crash, I'll even argue seeing the
> > interleaved printks would provide a hint to why it crashed.
> 
> Ok, so what do you want to do here?  Fix up your RFC patch to not have
> the printk stamps?  Or something like the above rt patch?
> 

I'm fine with adding a printk_flush() or even as Joe suggested, making a
pr_flush(), or printk(KERN_FLUSH "..." that will just do it. Maybe make
that default with a switch.

As to get rid of the time stamp issue, that may take a bit, as the code
goes through layers where this information needs to be passed down. I
ran 'trace-cmd record -p function_graph -g printk' to see how the flow
works, mounted an NFS filesystem (to force a printk) and this is what I
got:

  printk() {
    vprintk_emit() {
      _raw_spin_lock();
      log_store();
      console_trylock() {
        down_trylock() {
          _raw_spin_lock_irqsave();
          _raw_spin_unlock_irqrestore();
        }
      }
      console_unlock() {
        _raw_spin_lock_irqsave();
        log_from_idx();
        msg_print_text() {
          print_prefix();
          print_prefix();
        }
        log_next();
        serial8250_console_write() {

What's missing (as are all lib/ functions are from function tracing) is
the first call to vscnprintf() to get the string and all its args
together.

Then the '\n' is checked as well as the '<X>' notations. The prefix is
set for everything but '<c>' which makes sense, as you don't want to add
a prefix to a KERN_CONT line. But this 'prefix' variable just changes
the logic, it doesn't really prevent the prefix from appearing as we
will see.

Now things are a bit different if there's a newline or not. In this
trace, the newline was there, but first lets look at what happens when
there's no newline.

It checks this static variable called 'cont_len' which is set if we
buffered the last line. cont_task is set to the task it buffered too. If
cont_len is set but cont_task does not equal the current task, we call
this log_store() thingy. Which is the next thing that would have
happened if we did have a newline.

Now if cont_len is zero, it updates the current cont_level and
cont_task. Now it copies the printk into the cont_buf, which too is
static.

Finally, console_trylock() followed by console_unlock() which is done
regardless if there was a newline or not.

The console_unlock() is where the magic happens. Remember that
log_store() thingy, that's what is going to be printed. But remember, it
only was called if we had a newline, or we had buffered data and the
current task is different. But the current printk line is still located
in that cont_buf variable which happens to be static for vprintk_emit()
and not available elsewhere.

Once data is sent to the log_store() it always prints this prefix. This
is why my printk_flush() caused the next (<c>) line to have a timestamp
too. Because when that got flushed out, it got a timestamp on it, as all
data that goes to the console gets a timestamp. The only reason it
doesn't in the current method, is that it buffers it locally in the
cont_buf[] array, before it sends it out to the console. When it does
send it out to the console, it sends the entire buffer.

I forgot to mention what happens when the line has a newline, and
there's content in cont_buf[]. If the cont_task is the same as current,
it appends the cont_buf to the new data that is about to be printed, and
then sends that out to the log_store() which will get a timestamp at the
beginning of the line before the buffered data.

Oh, and one more thing. The vprintk_emit() strips the newline from the
text even if it had one. The msg_print_text() called by console_unlock()
and a bunch of syslog callers, adds the '\n' back. This is to all text
going out. My patch added a msg flag to say "don't do that!"  We also
need a flag to skip adding the timestamp, but that looks even more
complex, as the timestamp is added by print_prefix() also called by
msg_print_text() (three callers) and there's no comments to what the
frick it's doing or why. We need a way to stop that from happening.


-- Steve

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Ingo Molnar]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> On Mon, 2012-06-18 at 16:03 -0700, Greg Kroah-Hartman wrote:
> 
> > > Actually, I think that patch really should go mainline, and give others
> > > some of the luxury that us -rt folks enjoy.
> > 
> > That would be good.
> 
> Maybe I'll package that up if Ingo has no objections.

No objection, but I see it as an independent improvement.

Please also make printk() more useful out of box and fix the 
flushing bug ...

So mind re-sending the latest version of your printk flushing 
fix? I'll apply it for v3.5-rc if other trees won't pick it up.

Thanks,

	Ingo

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Greg Kroah-Hartman]

On Wed, Jun 20, 2012 at 02:25:49PM +0200, Ingo Molnar wrote:
> 
> * Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > On Mon, 2012-06-18 at 16:03 -0700, Greg Kroah-Hartman wrote:
> > 
> > > > Actually, I think that patch really should go mainline, and give others
> > > > some of the luxury that us -rt folks enjoy.
> > > 
> > > That would be good.
> > 
> > Maybe I'll package that up if Ingo has no objections.
> 
> No objection, but I see it as an independent improvement.
> 
> Please also make printk() more useful out of box and fix the 
> flushing bug ...
> 
> So mind re-sending the latest version of your printk flushing 
> fix? I'll apply it for v3.5-rc if other trees won't pick it up.

I'll be glad to pick it up, just make it work properly :)

thanks,

greg k-h

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Steven Rostedt]

On Thu, 2012-06-21 at 10:13 -0700, Greg Kroah-Hartman wrote:

> > So mind re-sending the latest version of your printk flushing 
> > fix? I'll apply it for v3.5-rc if other trees won't pick it up.
> 
> I'll be glad to pick it up, just make it work properly :)

I'm playing around with making a KERN_FLUSH "<f>". Think that's a better
approach?

-- Steve

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Joe Perches]

On Thu, 2012-06-21 at 13:41 -0400, Steven Rostedt wrote:
> On Thu, 2012-06-21 at 10:13 -0700, Greg Kroah-Hartman wrote:
> 
> > > So mind re-sending the latest version of your printk flushing 
> > > fix? I'll apply it for v3.5-rc if other trees won't pick it up.
> > 
> > I'll be glad to pick it up, just make it work properly :)
> 
> I'm playing around with making a KERN_FLUSH "<f>". Think that's a better
> approach?

I don't think that's better.  I think it's worse
because it intermixes the idea of a kernel message
logging level with a specific functionality to
emit any fragmentary message immediately.

I think a global setting via a some functions like:

(printk private variable)
bool printk_buffered = true;

bool printk_set_buffering(bool enable)
{
	bool old_state = printk_buffered;
	printk_buffered = enable;

	return old_state;
}

and maybe:

bool printk_get_buffering(void)
{
	return printk_buffered;
}

would be better because the non-buffered use should
really be pretty isolated to last_breath type output
and to pretty isolated cases like your long running
tests.

A separate printk_flush() function if really necessary
but sprinking a bunch of printk_flush() calls seems
wasteful.

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Joe Perches]

On Thu, 2012-06-21 at 11:17 -0700, Joe Perches wrote:
> bool printk_set_buffering(bool enable)
> {
> 	bool old_state = printk_buffered;
> 	printk_buffered = enable;

I suppose that should really be a counter
with an atomic inc/dec.

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Steven Rostedt]

On Thu, 2012-06-21 at 11:17 -0700, Joe Perches wrote:
> On Thu, 2012-06-21 at 13:41 -0400, Steven Rostedt wrote:
> > On Thu, 2012-06-21 at 10:13 -0700, Greg Kroah-Hartman wrote:
> > 
> > > > So mind re-sending the latest version of your printk flushing 
> > > > fix? I'll apply it for v3.5-rc if other trees won't pick it up.
> > > 
> > > I'll be glad to pick it up, just make it work properly :)
> > 
> > I'm playing around with making a KERN_FLUSH "<f>". Think that's a better
> > approach?
> 
> I don't think that's better.  I think it's worse
> because it intermixes the idea of a kernel message
> logging level with a specific functionality to
> emit any fragmentary message immediately.

Are you using a 50 char width terminal?

> 
> I think a global setting via a some functions like:
> 
> (printk private variable)
> bool printk_buffered = true;
> 
> bool printk_set_buffering(bool enable)
> {
> 	bool old_state = printk_buffered;
> 	printk_buffered = enable;
> 
> 	return old_state;
> }
> 
> and maybe:
> 
> bool printk_get_buffering(void)
> {
> 	return printk_buffered;
> }
> 
> would be better because the non-buffered use should
> really be pretty isolated to last_breath type output
> and to pretty isolated cases like your long running
> tests.
> 
> A separate printk_flush() function if really necessary
> but sprinking a bunch of printk_flush() calls seems
> wasteful.

A global buffering disable may cause other things that are printed to be
screwed up. Something that actually expects to be buffered. Which is why
I'm leaning to the log level version. As it keeps it contained to the
actual printk that does not want buffering.

Or perhaps have printk_flush() become a new printk. That is,
printk_flush("this does not buffer").

-- Steve

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Joe Perches]

On Thu, 2012-06-21 at 14:29 -0400, Steven Rostedt wrote:
> On Thu, 2012-06-21 at 11:17 -0700, Joe Perches wrote:
> > On Thu, 2012-06-21 at 13:41 -0400, Steven Rostedt wrote:
[]
> > > I'm playing around with making a KERN_FLUSH "<f>". Think that's a better
> > > approach?
> > 
> > I don't think that's better.  I think it's worse
> > because it intermixes the idea of a kernel message
> > logging level with a specific functionality to
> > emit any fragmentary message immediately.
> 
> Are you using a 50 char width terminal?

Nope.  Just an old habit.

> > 
> > I think a global setting via a some functions like:
> > 
> > (printk private variable)
> > bool printk_buffered = true;
> > 
> > bool printk_set_buffering(bool enable)
> > {
> > 	bool old_state = printk_buffered;
> > 	printk_buffered = enable;
> > 
> > 	return old_state;
> > }
> > 
> > and maybe:
> > 
> > bool printk_get_buffering(void)
> > {
> > 	return printk_buffered;
> > }
> > 
> > would be better because the non-buffered use should
> > really be pretty isolated to last_breath type output
> > and to pretty isolated cases like your long running
> > tests.
> > 
> > A separate printk_flush() function if really necessary
> > but sprinkling a bunch of printk_flush() calls seems
> > wasteful.
> 
> A global buffering disable may cause other things that are printed to be
> screwed up.

After Kay's deferral patch (an actual improvement), lots
of output could have been changed.  Turning off buffering
would simply revert to pre 3.5 behavior.  I don't think
that's a significant issue.

> Something that actually expects to be buffered.

There is nothing today that _expects_ buffering or is
guaranteed non-buffered.

The locations that benefit from non-buffering are few
and isolated.

> Or perhaps have printk_flush() become a new printk. That is,
> printk_flush("this does not buffer").

Yuck.

Then there'd be all the likely variants for
prefix [pr|dev|netdev]_<level>[_once|_ratelimited] postfix
too.

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Steven Rostedt]

On Thu, 2012-06-21 at 11:39 -0700, Joe Perches wrote:

> > A global buffering disable may cause other things that are printed to be
> > screwed up.
> 
> After Kay's deferral patch (an actual improvement), lots
> of output could have been changed.  Turning off buffering
> would simply revert to pre 3.5 behavior.  I don't think
> that's a significant issue.

But prints that actually require buffering disabled (like the one I'm
using) does so because it may be testing something that may crash the
system. On SMP, that crash could cause garbled output. Yes, it is pre
3.5 behavior, but why have garbled output on the crash when Kay went
through all that effort to have it work.


> 
> > Something that actually expects to be buffered.
> 
> There is nothing today that _expects_ buffering or is
> guaranteed non-buffered.

I'm not saying there is. But if the new buffering system is here, then
there may be something that will _expect_ buffering to be enabled.

> 
> The locations that benefit from non-buffering are few
> and isolated.

Which means we can use individual flushing.

> 
> > Or perhaps have printk_flush() become a new printk. That is,
> > printk_flush("this does not buffer").
> 
> Yuck.
> 
> Then there'd be all the likely variants for
> prefix [pr|dev|netdev]_<level>[_once|_ratelimited] postfix
> too.

Actually, I'm starting to lean back to my original patch, and stick a
pr_flush() in there. As it basically just acts like a barrier. "Make
sure the output I printed actually gets out to the console before I
continue".

-- Steve

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Joe Perches]

On Thu, 2012-06-21 at 14:49 -0400, Steven Rostedt wrote:
> Actually, I'm starting to lean back to my original patch, and stick a
> pr_flush() in there.

Oh good.  I think that's better than a new printk.

> As it basically just acts like a barrier. "Make
> sure the output I printed actually gets out to the console before I
> continue".

I think that'd be bad and hard to do.

I think you mean simply attempt to deliver it
rather than guarantee it's actually emitted.

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Steven Rostedt]

On Thu, 2012-06-21 at 11:55 -0700, Joe Perches wrote:

> > As it basically just acts like a barrier. "Make
> > sure the output I printed actually gets out to the console before I
> > continue".
> 
> I think that'd be bad and hard to do.
> 
> I think you mean simply attempt to deliver it
> rather than guarantee it's actually emitted.
> 

You mean due to contention on the printk console_sem?

It should be delivered, but sure, if something else is already in the
process of printing, and then the system crashes, the system is still
acting the same as it did pre 3.5.

-- Steve

[RFC PATCH] printk: Enable/disable buffering and add printk_flush()

[Joe Perches]

Add functions to enable/disable printk buffering.
Add a function to force any buffered output to be emitted.

printk_flush() also emits "printk_flush\n" at KERN_DEFAULT.

---

Perhaps something like this instead of just the one printk_flush()?
Doesn't require any additional KERN_LEVEL '<f>' addition.

Compiled but completely untested...

 include/linux/printk.h |   18 ++++++++++++++++++
 kernel/printk.c        |   36 ++++++++++++++++++++++++++++++++++--
 2 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 1bec2f7..165b6a2 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -111,6 +111,11 @@ asmlinkage int printk_emit(int facility, int level,
 asmlinkage __printf(1, 2) __cold
 int printk(const char *fmt, ...);
 
+bool printk_set_buffering(bool enable);
+bool printk_get_buffering(void);
+void printk_flush(void);	/* forcibly emit any internal buffers */
+
+
 /*
  * Special printk facility for scheduler use only, _DO_NOT_USE_ !
  */
@@ -143,6 +148,17 @@ int printk(const char *s, ...)
 {
 	return 0;
 }
+static bool printk_set_buffering(bool enable)
+{
+	return false;
+}
+bool printk_get_buffering(void)
+{
+	return false;
+}
+static inline void printk_flush(void)
+{
+}
 static inline __printf(1, 2) __cold
 int printk_sched(const char *s, ...)
 {
@@ -191,6 +207,8 @@ extern void dump_stack(void) __cold;
 #define pr_cont(fmt, ...) \
 	printk(KERN_CONT fmt, ##__VA_ARGS__)
 
+#define pr_flush printk_flush
+
 /* pr_devel() should produce zero code unless DEBUG is defined */
 #ifdef DEBUG
 #define pr_devel(fmt, ...) \
diff --git a/kernel/printk.c b/kernel/printk.c
index a2276b9..0e35931 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -1144,6 +1144,23 @@ module_param(ignore_loglevel, bool, S_IRUGO | S_IWUSR);
 MODULE_PARM_DESC(ignore_loglevel, "ignore loglevel setting, to"
 	"print all kernel messages to the console.");
 
+atomic_t printk_buffering = ATOMIC_INIT(1);
+
+bool printk_set_buffering(bool enable)
+{
+	if (enable)
+		return atomic_inc_and_test(&printk_buffering);
+
+	return atomic_dec_and_test(&printk_buffering);
+}
+EXPORT_SYMBOL(printk_set_buffering);
+
+bool printk_get_buffering(void)
+{
+        return atomic_read(&printk_buffering);
+}
+EXPORT_SYMBOL(printk_get_buffering);
+
 /*
  * Call the console drivers, asking them to write out
  * log_buf[start] to log_buf[end - 1].
@@ -1288,6 +1305,7 @@ asmlinkage int vprintk_emit(int facility, int level,
 	int this_cpu;
 	bool newline = false;
 	bool prefix = false;
+	bool buffered = atomic_read(&printk_buffering);
 	int printed_len = 0;
 
 	boot_delay_msec();
@@ -1355,8 +1373,16 @@ asmlinkage int vprintk_emit(int facility, int level,
 		}
 	}
 
-	if (level == -1)
+	switch (level) {
+	case -1:
 		level = default_message_loglevel;
+		break;
+	case -2:
+		prefix = true;
+		level = default_message_loglevel;
+		buffered = false;
+		break;
+	}
 
 	if (dict) {
 		prefix = true;
@@ -1364,7 +1390,7 @@ asmlinkage int vprintk_emit(int facility, int level,
 	}
 
 	if (!newline) {
-		if (cont_len && (prefix || cont_task != current)) {
+		if (cont_len && (prefix || cont_task != current || !buffered)) {
 			/*
 			 * Flush earlier buffer, which is either from a
 			 * different thread, or when we got a new prefix.
@@ -1454,6 +1480,12 @@ asmlinkage int printk_emit(int facility, int level,
 }
 EXPORT_SYMBOL(printk_emit);
 
+void printk_flush(void)
+{
+	printk_emit(0, -2, NULL, 0, "printk_flush\n");
+}
+EXPORT_SYMBOL(printk_flush);
+
 /**
  * printk - print a kernel message
  * @fmt: format string

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Ingo Molnar]

* Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Fri, Jun 15, 2012 at 02:04:30PM +0200, Ingo Molnar wrote:
> > 
> > * Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > 
> > > On Fri, Jun 15, 2012 at 12:22:33PM +0800, Fengguang Wu wrote:
> > > > > I actually would like to make these more compact. As all my test box
> > > > > consoles go through serial ports, just booting through this takes more
> > > > > time the the compile itself.
> > > > 
> > > > The tests took 23 seconds boot time on one kernel:
> > > > 
> > > >         [    0.152934] Testing tracer nop: PASSED
> > > >         ...1577 lines total...
> > > >         [   23.206550] Testing kprobe tracing: OK
> > > > 
> > > > And 135 seconds in another bloated kernel:
> > > > 
> > > >         [  115.396441] Testing event 9p_client_req: OK
> > > >         ...2545 lines total...
> > > >         [  240.268783] Testing kprobe tracing: OK
> > > > 
> > > > I'd appreciate if the boot time can be reduced. Because I'm doing
> > > > kernel boot tests for *every single* commits.
> > > > 
> > > > It may look insane amount of work, but it's still manageable: with 10
> > > > kvm instances each take 1 minute to boot test a kernel, I can boot
> > > > test 60*24*10=14400 kernels in one day. That's a rather big number.
> > > > That allows me to run more cpu/vm/io stress tests for each kernel :-)
> > > 
> > > Do you really want to enable those tests for your test 
> > > kernels?  Can they fail if we mess up other parts of the 
> > > kernel, or do they only test the tracing portions?
> > 
> > These printk's are useful, are used for a specific (albeit 
> > limited) purpose and were and continue to be useful in that 
> > role.
> > 
> > The changes Steve bisected to broke this use of printk().
> 
> And note, fixed others :)

Sorry, the "we fix some bugs and introduce others" stance is not 
a valid response to a regression. Either fix *all* regressions 
or revert the original change. Simple and robust policy, isn't 
it?

> > Please apply Steve's fix, fix it yourself or revert the 
> > changes that regressed printk().
> 
> I thought Steve's patch was just a RFC thing, is it really 
> something that everyone wants to see applied?

You mean the adding of an API to flush buffered output when 
that's the desired outcome? Why the heck should we *not* want 
that? Either I'm the weird one or you are being difficult ;-)

Thanks,

	Ingo

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Joe Perches]

On Sat, 2012-06-16 at 08:59 +0200, Ingo Molnar wrote:
> * Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > On Fri, Jun 15, 2012 at 02:04:30PM +0200, Ingo Molnar wrote:
> > > These printk's are useful, are used for a specific (albeit 
> > > limited) purpose and were and continue to be useful in that 
> > > role.
> > > 
> > > The changes Steve bisected to broke this use of printk().
> > 
> > And note, fixed others :)
> 
> Sorry, the "we fix some bugs and introduce others" stance is not 
> a valid response to a regression. Either fix *all* regressions 
> or revert the original change. Simple and robust policy, isn't 
> it?
> 
> > > Please apply Steve's fix, fix it yourself or revert the 
> > > changes that regressed printk().
> > 
> > I thought Steve's patch was just a RFC thing, is it really 
> > something that everyone wants to see applied?
> 
> You mean the adding of an API to flush buffered output when 
> that's the desired outcome? Why the heck should we *not* want 
> that? Either I'm the weird one or you are being difficult ;-)

The API might be better as a global flag
not a per-site flush.

Maybe printk_is_buffered(true/false)

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Greg Kroah-Hartman]

On Sat, Jun 16, 2012 at 05:51:27AM -0700, Joe Perches wrote:
> On Sat, 2012-06-16 at 08:59 +0200, Ingo Molnar wrote:
> > * Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > On Fri, Jun 15, 2012 at 02:04:30PM +0200, Ingo Molnar wrote:
> > > > These printk's are useful, are used for a specific (albeit 
> > > > limited) purpose and were and continue to be useful in that 
> > > > role.
> > > > 
> > > > The changes Steve bisected to broke this use of printk().
> > > 
> > > And note, fixed others :)
> > 
> > Sorry, the "we fix some bugs and introduce others" stance is not 
> > a valid response to a regression. Either fix *all* regressions 
> > or revert the original change. Simple and robust policy, isn't 
> > it?
> > 
> > > > Please apply Steve's fix, fix it yourself or revert the 
> > > > changes that regressed printk().
> > > 
> > > I thought Steve's patch was just a RFC thing, is it really 
> > > something that everyone wants to see applied?
> > 
> > You mean the adding of an API to flush buffered output when 
> > that's the desired outcome? Why the heck should we *not* want 
> > that? Either I'm the weird one or you are being difficult ;-)
> 
> The API might be better as a global flag
> not a per-site flush.
> 
> Maybe printk_is_buffered(true/false)

Hm, that sounds a bit better, and I thin it would solve the timestamp
problem that the proposed patch has, right?  We would then just
timestamp on a new line, as we should "know" when that happens?

Steven, do you like this idea better?

thanks,

greg k-h

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Greg Kroah-Hartman]

On Sat, Jun 16, 2012 at 08:59:03AM +0200, Ingo Molnar wrote:
> 
> * Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> 
> > On Fri, Jun 15, 2012 at 02:04:30PM +0200, Ingo Molnar wrote:
> > > 
> > > * Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > 
> > > > On Fri, Jun 15, 2012 at 12:22:33PM +0800, Fengguang Wu wrote:
> > > > > > I actually would like to make these more compact. As all my test box
> > > > > > consoles go through serial ports, just booting through this takes more
> > > > > > time the the compile itself.
> > > > > 
> > > > > The tests took 23 seconds boot time on one kernel:
> > > > > 
> > > > >         [    0.152934] Testing tracer nop: PASSED
> > > > >         ...1577 lines total...
> > > > >         [   23.206550] Testing kprobe tracing: OK
> > > > > 
> > > > > And 135 seconds in another bloated kernel:
> > > > > 
> > > > >         [  115.396441] Testing event 9p_client_req: OK
> > > > >         ...2545 lines total...
> > > > >         [  240.268783] Testing kprobe tracing: OK
> > > > > 
> > > > > I'd appreciate if the boot time can be reduced. Because I'm doing
> > > > > kernel boot tests for *every single* commits.
> > > > > 
> > > > > It may look insane amount of work, but it's still manageable: with 10
> > > > > kvm instances each take 1 minute to boot test a kernel, I can boot
> > > > > test 60*24*10=14400 kernels in one day. That's a rather big number.
> > > > > That allows me to run more cpu/vm/io stress tests for each kernel :-)
> > > > 
> > > > Do you really want to enable those tests for your test 
> > > > kernels?  Can they fail if we mess up other parts of the 
> > > > kernel, or do they only test the tracing portions?
> > > 
> > > These printk's are useful, are used for a specific (albeit 
> > > limited) purpose and were and continue to be useful in that 
> > > role.
> > > 
> > > The changes Steve bisected to broke this use of printk().
> > 
> > And note, fixed others :)
> 
> Sorry, the "we fix some bugs and introduce others" stance is not 
> a valid response to a regression. Either fix *all* regressions 
> or revert the original change. Simple and robust policy, isn't 
> it?

You are right, to a point :)

> > > Please apply Steve's fix, fix it yourself or revert the 
> > > changes that regressed printk().
> > 
> > I thought Steve's patch was just a RFC thing, is it really 
> > something that everyone wants to see applied?
> 
> You mean the adding of an API to flush buffered output when 
> that's the desired outcome? Why the heck should we *not* want 
> that? Either I'm the weird one or you are being difficult ;-)

Sorry, no, I was referring to the fact that he said he didn't really
like it because of the timestamp garbage in the line.

thanks,

greg k-h

[PATCH] printk: Add printk_flush() to force buffered text to console

[Steven Rostedt]

Fengguang Wu had a config that caused the system to lockup. It reported:

[    6.086395] type=2000 audit(1339501575.085:1): initialized
[    6.116356] Kprobe smoke test started
[    6.125915] Kprobe smoke test passed successfully
[    6.127478] rcu-torture:--- Start of test: nreaders=2 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0
+fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4 shutdown_secs=0 onoff_interval=0 onoff_holdoff=0

and then froze. So naturally, the suspected bug was with rcu-torture.
Fengguang did a git bisect and discovered that the crash came with a
function trace update. He also noticed that if he reverted that update,
the system got farther and showed:

[    1.611901] Testing tracer function: PASSED

His time was wasted by the fact that the function tracing self test
first prints:

  "Testing tracer function: "

then runs the test, and if it succeeds, it prints "PASSED", giving us
the nice output you see above.

But with the new printk() changes, text without a newline gets buffered
and does not print out to the console at the location of the printk.
This caused the "Testing tracer function: " not to print out and because
the test caused the kernel to lock up, we are clueless to the fact that
the problem was with the function tracer test and not the rcu_torture
test. As it made sense that the rcu_torture test could lock up the
system, many kernel developer hours were wasted chasing the wrong wild
goose.

If the "Testing tracer function: " had printed out in the first place,
we would have caught the correct wild goose and saved precious kernel
developer's time.

Thus a need for the following utility. That is to add a 'printk_flush()'
that acts like a fflush() in userspace to flush out the buffers used by
the printing facility so we don't have unexpected hunts for nature
roaming fowl.

I hooked onto the 'facility' infrastructure and used '0x1ffc' (the max
number) as a way to communicate printk() commands to the msg_print_text()
which is performed at a later time (console_unlock()).

I tested this out, (adding pr_flush() after my printk) and now the
lockup shows:

[    9.018231] Kprobe smoke test passed successfully
[    9.023084] rcu-torture:--- Start of test: nreaders=4 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_hold
off=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4 shutdown_secs=0 onoff_interval=0 onoff_holdoff=0
[    9.066065] Testing tracer function:

To prevent the flush to cause the next printk to have a timestamp that
would produce the following:

[    6.834073] Testing tracer function: [    7.136194] PASSED

I made the KERN_CONT ("<c>") use the facility as well to pass info to
not print the timestamp. This fixes the abve issue to print:

[    1.291025] Testing tracer function: PASSED

Link: http://lkml.kernel.org/r/1339649173.13377.191.camel@gandalf.stny.rr.com

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "kay.sievers" <kay.sievers@vrfy.org>
Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
 include/linux/printk.h |    8 ++++
 kernel/printk.c        |  104 ++++++++++++++++++++++++++++++++++++++++++-----
 2 files changed, 101 insertions(+), 11 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 1bec2f7..b3317bf3 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -111,6 +111,8 @@ asmlinkage int printk_emit(int facility, int level,
 asmlinkage __printf(1, 2) __cold
 int printk(const char *fmt, ...);
 
+void printk_flush(void);
+
 /*
  * Special printk facility for scheduler use only, _DO_NOT_USE_ !
  */
@@ -158,6 +160,10 @@ static inline bool printk_timed_ratelimit(unsigned long *caller_jiffies,
 	return false;
 }
 
+static inline void printk_flush(void)
+{
+}
+
 static inline void log_buf_kexec_setup(void)
 {
 }
@@ -190,6 +196,8 @@ extern void dump_stack(void) __cold;
 	printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
 #define pr_cont(fmt, ...) \
 	printk(KERN_CONT fmt, ##__VA_ARGS__)
+#define pr_flush() \
+	printk_flush()
 
 /* pr_devel() should produce zero code unless DEBUG is defined */
 #ifdef DEBUG
diff --git a/kernel/printk.c b/kernel/printk.c
index 32462d2..ca1f5ff 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -237,6 +237,24 @@ static char __log_buf[__LOG_BUF_LEN] __aligned(LOG_ALIGN);
 static char *log_buf = __log_buf;
 static u32 log_buf_len = __LOG_BUF_LEN;
 
+/*
+ * The max number for facility is 0xffff >> 3, or 0x1fff.
+ * As log facilities count upward from 1, we have the kernel
+ * keep the top numbers or itself.
+ *
+ * 0x1ffc is the code for kernel processing in msg->level (facility)
+ * bit 0 - do not print prefix
+ * bit 1 - do not print newline
+ */
+#define LOG_KERNEL		0x1ffc
+#define LOG_NONL_NOPREFIX_MSK	3
+#define LOG_NONL_SET		2
+#define LOG_NOPREFIX_SET	1
+
+#define LOG_NONL_NOPREFIX	(LOG_KERNEL | LOG_NONL_NOPREFIX_MSK)
+#define LOG_NONL		(LOG_KERNEL | LOG_NONL_SET)
+#define LOG_NOPREFIX		(LOG_KERNEL | LOG_NOPREFIX_SET)
+
 /* cpu currently holding logbuf_lock */
 static volatile unsigned int logbuf_cpu = UINT_MAX;
 
@@ -836,14 +854,36 @@ static size_t msg_print_text(const struct log *msg, bool syslog,
 		}
 
 		if (buf) {
-			if (print_prefix(msg, syslog, NULL) +
-			    text_len + 1>= size - len)
-				break;
+			int newline = 1;
+			int prefix = 1;
+			int facility = msg->level >> 3;
+
+			/*
+			 * The kernel sends some commands via the facility.
+			 * To do so, a high number mask is used (LOG_KERNEL)
+			 * and the low bits of the mask hold the command bits
+			 * that the kernel printk() will use to state how the
+			 * msg will be printed.
+			 */
+			if ((facility & LOG_KERNEL) == LOG_KERNEL) {
+				if (facility & LOG_NOPREFIX_SET)
+					prefix = 0;
+				if (facility & LOG_NONL_SET)
+					newline = 0;
+			}
+
+			if (prefix) {
+				if (print_prefix(msg, syslog, NULL) +
+				    text_len + 1 >= size - len)
+					break;
+
+				len += print_prefix(msg, syslog, buf + len);
+			}
 
-			len += print_prefix(msg, syslog, buf + len);
 			memcpy(buf + len, text, text_len);
 			len += text_len;
-			buf[len++] = '\n';
+			if (newline)
+				buf[len++] = '\n';
 		} else {
 			/* SYSLOG_ACTION_* buffer size only calculation */
 			len += print_prefix(msg, syslog, NULL);
@@ -1267,6 +1307,7 @@ asmlinkage int vprintk_emit(int facility, int level,
 	static char cont_buf[LOG_LINE_MAX];
 	static size_t cont_len;
 	static int cont_level;
+	static bool cont_prefix;
 	static struct task_struct *cont_task;
 	static char textbuf[LOG_LINE_MAX];
 	char *text = textbuf;
@@ -1275,6 +1316,7 @@ asmlinkage int vprintk_emit(int facility, int level,
 	int this_cpu;
 	bool newline = false;
 	bool prefix = false;
+	bool flush = false;
 	int printed_len = 0;
 
 	boot_delay_msec();
@@ -1339,18 +1381,37 @@ asmlinkage int vprintk_emit(int facility, int level,
 		case 'c':	/* KERN_CONT */
 			text += 3;
 			text_len -= 3;
+			break;
+		case 'f':	/* KERN_FLUSH - used internally */
+			flush = true;
 		}
 	}
 
-	if (level == -1)
-		level = default_message_loglevel;
+	if (!flush) {
+		if (level == -1)
+			level = default_message_loglevel;
 
-	if (dict) {
-		prefix = true;
-		newline = true;
+		if (dict) {
+			prefix = true;
+			newline = true;
+		}
 	}
 
-	if (!newline) {
+	if (flush) {
+		if (cont_len) {
+			int code = LOG_NONL;
+
+			/*
+			 * If the buffered string was KERN_CONT,
+			 * do not print prefix.
+			 */
+			if (!cont_prefix)
+				code = LOG_NONL_NOPREFIX;
+			log_store(code, cont_level, NULL, 0, cont_buf, cont_len);
+			cont_len = 0;
+		}
+
+	} else if (!newline) {
 		if (cont_len && (prefix || cont_task != current)) {
 			/*
 			 * Flush earlier buffer, which is either from a
@@ -1363,6 +1424,7 @@ asmlinkage int vprintk_emit(int facility, int level,
 		if (!cont_len) {
 			cont_level = level;
 			cont_task = current;
+			cont_prefix = prefix;
 		}
 
 		/* buffer or append to earlier buffer from the same thread */
@@ -1395,6 +1457,8 @@ asmlinkage int vprintk_emit(int facility, int level,
 			printed_len = cont_len;
 		} else {
 			/* ordinary single and terminated line */
+			if (!prefix && !facility && cont_task == current)
+				facility = LOG_NOPREFIX;
 			log_store(facility, level,
 				  dict, dictlen, text, text_len);
 			printed_len = text_len;
@@ -1483,6 +1547,24 @@ asmlinkage int printk(const char *fmt, ...)
 }
 EXPORT_SYMBOL(printk);
 
+/**
+ * printk_flush - flush out any buffered text
+ *
+ * printk() will buffer text and not write it out to the console
+ * if the text was missing a newline. If it is required to get text
+ * out to the console without a newline, use printk_flush() and it
+ * will do that. This is useful when running self tests, where you
+ * have a line that prints what is being tested, and then if it
+ * passed or failed after the test, and you want this all done on
+ * a single line. Without flushing, if the test crashes, you may
+ * never see what was being tested.
+ */
+void printk_flush(void)
+{
+	printk("<f>");
+}
+EXPORT_SYMBOL(printk_flush);
+
 #else
 
 #define LOG_LINE_MAX 0
-- 
1.7.3.4

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Ingo Molnar]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> Fengguang Wu had a config that caused the system to lockup. It reported:
> 
> [    6.086395] type=2000 audit(1339501575.085:1): initialized
> [    6.116356] Kprobe smoke test started
> [    6.125915] Kprobe smoke test passed successfully
> [    6.127478] rcu-torture:--- Start of test: nreaders=2 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0
> +fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4 shutdown_secs=0 onoff_interval=0 onoff_holdoff=0
> 
> and then froze. So naturally, the suspected bug was with rcu-torture.
> Fengguang did a git bisect and discovered that the crash came with a
> function trace update. He also noticed that if he reverted that update,
> the system got farther and showed:
> 
> [    1.611901] Testing tracer function: PASSED
> 
> His time was wasted by the fact that the function tracing self test
> first prints:
> 
>   "Testing tracer function: "
> 
> then runs the test, and if it succeeds, it prints "PASSED", giving us
> the nice output you see above.
> 
> But with the new printk() changes, text without a newline gets buffered
> and does not print out to the console at the location of the printk.
> This caused the "Testing tracer function: " not to print out and because
> the test caused the kernel to lock up, we are clueless to the fact that
> the problem was with the function tracer test and not the rcu_torture
> test. As it made sense that the rcu_torture test could lock up the
> system, many kernel developer hours were wasted chasing the wrong wild
> goose.
> 
> If the "Testing tracer function: " had printed out in the first place,
> we would have caught the correct wild goose and saved precious kernel
> developer's time.
> 
> Thus a need for the following utility. That is to add a 'printk_flush()'
> that acts like a fflush() in userspace to flush out the buffers used by
> the printing facility so we don't have unexpected hunts for nature
> roaming fowl.
> 
> I hooked onto the 'facility' infrastructure and used '0x1ffc' (the max
> number) as a way to communicate printk() commands to the msg_print_text()
> which is performed at a later time (console_unlock()).
> 
> I tested this out, (adding pr_flush() after my printk) and now the
> lockup shows:
> 
> [    9.018231] Kprobe smoke test passed successfully
> [    9.023084] rcu-torture:--- Start of test: nreaders=4 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_hold
> off=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4 shutdown_secs=0 onoff_interval=0 onoff_holdoff=0
> [    9.066065] Testing tracer function:
> 
> To prevent the flush to cause the next printk to have a timestamp that
> would produce the following:
> 
> [    6.834073] Testing tracer function: [    7.136194] PASSED
> 
> I made the KERN_CONT ("<c>") use the facility as well to pass info to
> not print the timestamp. This fixes the abve issue to print:
> 
> [    1.291025] Testing tracer function: PASSED
> 
> Link: http://lkml.kernel.org/r/1339649173.13377.191.camel@gandalf.stny.rr.com
> 
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: "kay.sievers" <kay.sievers@vrfy.org>
> Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
> Cc: Fengguang Wu <fengguang.wu@intel.com>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> ---
>  include/linux/printk.h |    8 ++++
>  kernel/printk.c        |  104 ++++++++++++++++++++++++++++++++++++++++++-----
>  2 files changed, 101 insertions(+), 11 deletions(-)

Maybe also add the actual usage sites, to demonstrate how it's 
going to be used?

Thanks,

	Ingo

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Steven Rostedt]

On Fri, 2012-06-22 at 09:17 +0200, Ingo Molnar wrote:

> Maybe also add the actual usage sites, to demonstrate how it's 
> going to be used?

Here's the places that I added (and tested) the pr_flush().

I even added 'set_current_task(TASK_UNINTERRUPTIBLE);
schedule_timeout(5*HZ);' to see if it does flush, and it worked fine.

-- Steve

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 49249c2..f7f2cd0 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -825,6 +825,7 @@ int register_tracer(struct tracer *type)
 
 		/* the test is responsible for initializing and enabling */
 		pr_info("Testing tracer %s: ", type->name);
+		pr_flush();
 		ret = type->selftest(type, tr);
 		/* the test is responsible for resetting too */
 		current_trace = saved_tracer;
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 29111da..84b674e 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1606,6 +1606,7 @@ static __init void event_trace_self_tests(void)
 #endif
 
 		pr_info("Testing event %s: ", call->name);
+		pr_flush();
 
 		/*
 		 * If an event is already enabled, someone is using
@@ -1635,6 +1636,7 @@ static __init void event_trace_self_tests(void)
 			continue;
 
 		pr_info("Testing event system %s: ", system->name);
+		pr_flush();
 
 		ret = __ftrace_set_clr_event(NULL, system->name, NULL, 1);
 		if (WARN_ON_ONCE(ret)) {
@@ -1657,6 +1659,7 @@ static __init void event_trace_self_tests(void)
 
 	pr_info("Running tests on all trace events:\n");
 	pr_info("Testing all events: ");
+	pr_flush();
 
 	ret = __ftrace_set_clr_event(NULL, NULL, NULL, 1);
 	if (WARN_ON_ONCE(ret)) {
diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
index 288541f..9638639 100644
--- a/kernel/trace/trace_selftest.c
+++ b/kernel/trace/trace_selftest.c
@@ -161,6 +161,7 @@ static void print_counts(void)
 	       trace_selftest_test_probe3_cnt,
 	       trace_selftest_test_global_cnt,
 	       trace_selftest_test_dyn_cnt);
+	pr_flush();
 }
 
 static void reset_counts(void)
@@ -184,6 +185,7 @@ static int trace_selftest_ops(int cnt)
 
 	printk(KERN_CONT "PASSED\n");
 	pr_info("Testing dynamic ftrace ops #%d: ", cnt);
+	pr_flush();
 
 	ftrace_enabled = 1;
 	reset_counts();
@@ -315,6 +317,7 @@ int trace_selftest_startup_dynamic_tracing(struct tracer *trace,
 	/* The ftrace test PASSED */
 	printk(KERN_CONT "PASSED\n");
 	pr_info("Testing dynamic ftrace: ");
+	pr_flush();
 
 	/* enable tracing, and record the filter function */
 	ftrace_enabled = 1;

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Joe Perches]

On Thu, 2012-06-21 at 19:52 -0400, Steven Rostedt wrote:
> Fengguang Wu had a config that caused the system to lockup. It reported:
[]

It'd have been nicer if you'd have cc'd me.

What I submitted is far simpler and it allows a knob
to control the printk buffering on a global basis.

Did you try it?  It seems to work here, but I don't
have your other patches to rcu-torture with inserted
printk_flush patches to verify it.  Can I have a
copy of those please.

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Steven Rostedt]

On Fri, 2012-06-22 at 01:24 -0700, Joe Perches wrote:
> On Thu, 2012-06-21 at 19:52 -0400, Steven Rostedt wrote:
> > Fengguang Wu had a config that caused the system to lockup. It reported:
> []
> 
> It'd have been nicer if you'd have cc'd me.

I didn't mean to be rude. I had pulled in my original patch which kept
the Cc list, and did a git --amend after making my changes and testing.
I just did a cut and paste to put back the Cc list.

> 
> What I submitted is far simpler and it allows a knob
> to control the printk buffering on a global basis.

But it did not handle the \n nor the timestamp prefix.

> 
> Did you try it?

No, because it did not do what I needed.

>   It seems to work here, but I don't
> have your other patches to rcu-torture with inserted
> printk_flush patches to verify it.  Can I have a
> copy of those please.

I just posted the places that I add it. There may be more places coming
too.

-- Steve

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Andrew Morton]

On Thu, 21 Jun 2012 19:52:03 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> But with the new printk() changes, text without a newline gets buffered
> and does not print out to the console at the location of the printk.

uh, how about we fix that?  The old behaviour was good, the new
behaviour is noxious.

Please idenfity these "new printk() changes".  Was the new noxiousness
an unavoidable effect of them?

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Steven Rostedt]

On Fri, 2012-06-22 at 14:54 -0700, Andrew Morton wrote:
> On Thu, 21 Jun 2012 19:52:03 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > But with the new printk() changes, text without a newline gets buffered
> > and does not print out to the console at the location of the printk.
> 
> uh, how about we fix that?  The old behaviour was good, the new
> behaviour is noxious.
> 
> Please idenfity these "new printk() changes".  Was the new noxiousness
> an unavoidable effect of them?

See commit 7ff9554bb578 ("printk: convert byte-buffer to variable-length
record buffer") and related commits.

But that said, there may be a way that I can make it still always flush
and not add a new API. We can flush on partial writes, and keep track of
the current task (as it already does). If a new task comes in, we can
then force a newline before printing the content of the old task (if
there wasn't a newline printed before).

This is basically what it does now, except that it buffers the data. If
a new task were to do a print in between the two partial writes, it
flushes what was buffered and adds a newline before printing the new
text.

I think I may be able to implement the same behavior, except that it
wont buffer. It would just keep track of the state of the last write.

-- Steve

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Andrew Morton]

On Fri, 22 Jun 2012 19:41:04 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Fri, 2012-06-22 at 14:54 -0700, Andrew Morton wrote:
> > On Thu, 21 Jun 2012 19:52:03 -0400
> > Steven Rostedt <rostedt@goodmis.org> wrote:
> > 
> > > But with the new printk() changes, text without a newline gets buffered
> > > and does not print out to the console at the location of the printk.
> > 
> > uh, how about we fix that?  The old behaviour was good, the new
> > behaviour is noxious.
> > 
> > Please idenfity these "new printk() changes".  Was the new noxiousness
> > an unavoidable effect of them?
> 
> See commit 7ff9554bb578 ("printk: convert byte-buffer to variable-length
> record buffer") and related commits.
> 
> But that said, there may be a way that I can make it still always flush
> and not add a new API. We can flush on partial writes, and keep track of
> the current task (as it already does). If a new task comes in, we can
> then force a newline before printing the content of the old task (if
> there wasn't a newline printed before).
> 
> This is basically what it does now, except that it buffers the data. If
> a new task were to do a print in between the two partial writes, it
> flushes what was buffered and adds a newline before printing the new
> text.

If a driver does

	printk("testing the frobnozzle ...");
	do_test();
	printk(" OK\n");

and do_test() hangs up, we really really want the user to know that
there was a frobnozzle testing problem.  Please tell me this isn't
broken.

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Steven Rostedt]

On Fri, 2012-06-22 at 16:49 -0700, Andrew Morton wrote:

> If a driver does
> 
> 	printk("testing the frobnozzle ...");
> 	do_test();
> 	printk(" OK\n");
> 
> and do_test() hangs up, we really really want the user to know that
> there was a frobnozzle testing problem.  Please tell me this isn't
> broken.

OK, then I wont tell you :-)  But this is exactly what happened to me.
There was a config that caused the function tracer self test to triple
fault the machine. The test does exactly what you just described:

	printk("Testing trace %s: ", tracer->name);
	ret = run_tests(tracer);
	if (ret == 0)
		printk("PASSED!\n");
	else
		printk("FAILED!\n");

But because of this new buffering, that didn't print. And unfortunately,
the previous printk was the start of the rcu torture test. Thus when
Fengguang saw that the last thing printed before his machine crashed was
the rcu torture tests starting, he obviously (but incorrectly) blamed it
on the rcu torture test.

Yes, I think this is broken by design. But I have an idea for a fix.
I'll work on it on Monday, and it wont require adding a pr_flush() like
I did in this patch set.

-- Steve

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Ingo Molnar]

* Andrew Morton <akpm@linux-foundation.org> wrote:

> On Thu, 21 Jun 2012 19:52:03 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > But with the new printk() changes, text without a newline 
> > gets buffered and does not print out to the console at the 
> > location of the printk.
> 
> uh, how about we fix that?  The old behaviour was good, the 
> new behaviour is noxious.

Absolutely.

pr_flush() really seems to be a workaround.

> Please idenfity these "new printk() changes".  Was the new 
> noxiousness an unavoidable effect of them?

Fundamentally:

e2ae715d66bf kmsg - kmsg_dump() use iterator to receive log buffer content
c313af145b9b printk() - isolate KERN_CONT users from ordinary complete lines
3ce9a7c0ac28 printk() - restore prefix/timestamp printing for multi-newline strings
649e6ee33f73 printk() - restore timestamp printing at console output
5c5d5ca51abd printk() - do not merge continuation lines of different threads
7f3a781d6fd8 printk - fix compilation for CONFIG_PRINTK=n
5fc3249068c1 kmsg: use do_div() to divide 64bit integer
e11fea92e13f kmsg: export printk records to the /dev/kmsg interface
7ff9554bb578 printk: convert byte-buffer to variable-length record buffer

Should we revert them or can they be fixed sanely? Kay seems to 
be busy with other things so I guess a revert is the best we can 
do. Greg, Kay?

Thanks,

	Ingo

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Joe Perches]

On Sat, 2012-06-23 at 08:13 +0200, Ingo Molnar wrote:
> * Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > On Thu, 21 Jun 2012 19:52:03 -0400
> > Steven Rostedt <rostedt@goodmis.org> wrote:
> > 
> > > But with the new printk() changes, text without a newline 
> > > gets buffered and does not print out to the console at the 
> > > location of the printk.
> > 
> > uh, how about we fix that?  The old behaviour was good, the 
> > new behaviour is noxious.
> 
> Absolutely.
> 
> pr_flush() really seems to be a workaround.

I think the new behavior an overall improvement.
It helps avoid multiple thread interleaving.

I suggested a fix to enable a printk buffered/non-buffered
mechanism with an optional printk_flush/pr_flush.

https://lkml.org/lkml/2012/6/21/305

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Ingo Molnar]

* Joe Perches <joe@perches.com> wrote:

> On Sat, 2012-06-23 at 08:13 +0200, Ingo Molnar wrote:
> > * Andrew Morton <akpm@linux-foundation.org> wrote:
> > 
> > > On Thu, 21 Jun 2012 19:52:03 -0400
> > > Steven Rostedt <rostedt@goodmis.org> wrote:
> > > 
> > > > But with the new printk() changes, text without a newline 
> > > > gets buffered and does not print out to the console at the 
> > > > location of the printk.
> > > 
> > > uh, how about we fix that?  The old behaviour was good, the 
> > > new behaviour is noxious.
> > 
> > Absolutely.
> > 
> > pr_flush() really seems to be a workaround.
> 
> I think the new behavior an overall improvement.
> It helps avoid multiple thread interleaving.
> 
> I suggested a fix to enable a printk buffered/non-buffered
> mechanism with an optional printk_flush/pr_flush.
> 
> https://lkml.org/lkml/2012/6/21/305

Ugh, so you suggest a global toggle to turn buffering on/off?

That approach really misses thole whole *point* of printk() and 
debug logging in particular. In most cases when users are 
triggering and reporting problems they don't go around toggling 
various rarely used switches to see whether they make a 
difference. They and kernel developers just take printk output 
at face value and trust it.

Even if people are aware of this global toggle there are 
frequent cases where a hang is probabilistic and occurs only 
very rarely. If a once a year bug triggers then it's obviously 
useful to have good debug output on the screen or in the serial 
log and not wait another year with the debug option turned on 
...

If I cannot trust printk output anymore and would have to toggle 
global switches to make it work then printk() has lost value for 
debugging kernel problems and that would be sad.

So NAK on your patch, really. We should either fix this 
regression in behavior, or, as a second best alternative we 
should at least give a deterministic way to flush the printk 
output, which works all the time.

Thanks,

	Ingo

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Joe Perches]

On Mon, 2012-06-25 at 10:45 +0200, Ingo Molnar wrote:
> * Joe Perches <joe@perches.com> wrote:
> 
> > On Sat, 2012-06-23 at 08:13 +0200, Ingo Molnar wrote:
> > > * Andrew Morton <akpm@linux-foundation.org> wrote:
> > > 
> > > > On Thu, 21 Jun 2012 19:52:03 -0400
> > > > Steven Rostedt <rostedt@goodmis.org> wrote:
> > > > 
> > > > > But with the new printk() changes, text without a newline 
> > > > > gets buffered and does not print out to the console at the 
> > > > > location of the printk.
> > > > 
> > > > uh, how about we fix that?  The old behaviour was good, the 
> > > > new behaviour is noxious.
> > > 
> > > Absolutely.
> > > 
> > > pr_flush() really seems to be a workaround.
> > 
> > I think the new behavior an overall improvement.
> > It helps avoid multiple thread interleaving.
> > 
> > I suggested a fix to enable a printk buffered/non-buffered
> > mechanism with an optional printk_flush/pr_flush.
> > 
> > https://lkml.org/lkml/2012/6/21/305
> 
> Ugh, so you suggest a global toggle to turn buffering on/off?

<shrug>

Rather than adding a bunch of printk_flush() calls around
the possibly many sites per file that need them, I'd rather
see a code block surrounded by buffer(false)/buffer(true).

I'd actually rather see the existing partial line uses like:

	printk("doing test_func: ");
	printk("%s\n", test_func(foo) ? "successful", "failed");

and

	printk("step 1")
	bar();
	printk(" - step 2");
	baz();
	printk("completed\n");
		
changed to whole lines rather than adding a bunch of
printk_flush() sites or the printk_buffering(on|off)
blocks.

Anyway, I suggested it shouldn't be merged awhile ago.

https://lkml.org/lkml/2012/5/22/439

Making systemic printk changes is a slow business.

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Kay Sievers]

On Sat, 2012-06-23 at 08:13 +0200, Ingo Molnar wrote:
> * Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > On Thu, 21 Jun 2012 19:52:03 -0400
> > Steven Rostedt <rostedt@goodmis.org> wrote:
> > 
> > > But with the new printk() changes, text without a newline 
> > > gets buffered and does not print out to the console at the 
> > > location of the printk.
> > 
> > uh, how about we fix that?  The old behaviour was good, the 
> > new behaviour is noxious.
> 
> Absolutely.
> 
> pr_flush() really seems to be a workaround.
> 
> > Please idenfity these "new printk() changes".  Was the new 
> > noxiousness an unavoidable effect of them?
> 
> Fundamentally:
> 
> e2ae715d66bf kmsg - kmsg_dump() use iterator to receive log buffer content
> c313af145b9b printk() - isolate KERN_CONT users from ordinary complete lines
> 3ce9a7c0ac28 printk() - restore prefix/timestamp printing for multi-newline strings
> 649e6ee33f73 printk() - restore timestamp printing at console output
> 5c5d5ca51abd printk() - do not merge continuation lines of different threads
> 7f3a781d6fd8 printk - fix compilation for CONFIG_PRINTK=n
> 5fc3249068c1 kmsg: use do_div() to divide 64bit integer
> e11fea92e13f kmsg: export printk records to the /dev/kmsg interface
> 7ff9554bb578 printk: convert byte-buffer to variable-length record buffer
> 
> Should we revert them or can they be fixed sanely? Kay seems to 
> be busy with other things so I guess a revert is the best we can 
> do. Greg, Kay?

I just don't have a better idea than Joe or Steven.

The conversion from the unreliable byte-buffer to records changes the
behavior a little in some areas. We are atomic at the line level now and
not at an sometimes unpredictable byte stream position which can just be
moved forward by adding another few bytes.

The usual continuation line user should all be buffered to make things
generally more reliable and less racy. And we really had these problems
in the past, and substantially improved the common use-cases now.

But yes, it seems to come into our way with the current output format of
the kernel self-tests, and we need to do something about it. But I don't
think it should be going back to the much-too-simple and unreliable
byte-stream buffer.

We need make some sort of a compromise for the self-tests here, I guess.
I think the trade of using one of these options for the self-tests to
cope with the new model is justified:
- flush explicitly when it is needed, by a global flag or with a
  message prefix
- printing a second full line that says: test foo OK, instead
  of appending the OK to the former line
- printing one full line, and suppress the later OK entirely. The OK
  might not be needed at all; we will find out that the machine
  has not crashed at that point and a message in case of an error
  could be sufficient in most cases.

Reverting the changes now would remove:
- proper device identifiers attached to a message, which allows
  tools for the first time to know the contexts of the kernel messages
- 100% message integrity of structured messages, and single line
  prints, and if only one continuation line user prints at a time.
  We never mix continuation users with full line users, like the
  old buffer did.
- very reliable continuation line prints, because of the buffering.
  The only race that can still happen is several cont users racing
  against each other, which is not too likely
- 100% granularity at line level during userspace buffer access,
  crash dumping; we never copy around half or overwritten lines,
  like the old buffer
- the ring buffer prunes only entire messages not just the half
  of a line like the old byte buffer
- sequence numbers allow us to track the state of the read and write
  position in the buffer, so we never copy in-the-meantime already
  overwritten messages around
- sequence numbers which allow userspace to reconnect to the old reading
  position and process only new messages, and find if messages got
  overwritten
- support for multiple concurrent readers with live update of the kernel
  log stream

This seems like a trade of a rather cosmetic output-format issue for
kernel self-tests, against general reliability, integrity and usefulness
of the rest of the kernel message users.

The record buffer is a huge step forward for the system logging, and it
allows us for the first time to make the kernel log useful to consumers
other than humans, and is key part of providing important information to
the system management.

An explicit flush for the self-test like users is unfortunate, and
inconvenient, and surely not nice, but I think it's still the better
overall deal.

Thanks,
Kay

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Fengguang Wu]

> - printing one full line, and suppress the later OK entirely. The OK
>   might not be needed at all; we will find out that the machine
>   has not crashed at that point and a message in case of an error
>   could be sufficient in most cases.

That looks neat and feasible.  We not only get less output, but also
eliminate the problem of flushing:

        [   16.309109] Testing tracer irqsoff: PASSED
        [   17.184240] Testing tracer wakeup: PASSED
        [   18.060218] Testing tracer wakeup_rt: PASSED
        [   18.729222] Testing tracer function_graph: PASSED
        ...thousands more lines
=>
        [   16.309109] Testing tracer irqsoff
        [   17.184240] Testing tracer wakeup
        [   18.060218] Testing tracer wakeup_rt
        [   18.729222] Testing tracer function_graph
        ...thousands more lines

However these two special lines will have to be broken up into more lines:

        [   14.947553] Testing dynamic ftrace ops #1: (1 0 1 1 0) (1 1 2 1 0) (2 1 3 1 26) (2 2 4 1 43) PASSED
        [   15.740993] Testing dynamic ftrace ops #2: (1 0 1 26 0) (1 1 2 43 0) (2 1 3 1 15) (2 2 4 18 32) PASSED

Thanks,
Fengguang

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Joe Perches]

On Sat, 2012-06-23 at 13:47 +0200, Kay Sievers wrote:
[]
> We need make some sort of a compromise for the self-tests here, I guess.
> I think the trade of using one of these options for the self-tests to
> cope with the new model is justified:
> - flush explicitly when it is needed, by a global flag or with a
>   message prefix

> - printing a second full line that says: test foo OK, instead
>   of appending the OK to the former line

This is probably the easiest actual fix.

> - printing one full line, and suppress the later OK entirely. The OK
>   might not be needed at all; we will find out that the machine
>   has not crashed at that point and a message in case of an error
>   could be sufficient in most cases.

I think the added timing information useful.

> Reverting the changes now would remove:
> - proper device identifiers attached to a message, which allows
>   tools for the first time to know the contexts of the kernel messages

I think this is not particularly true nor really useful at
present and the [v]printk_emit parts should be removed
until a the benefit of such a capability more proven.

I'm still concerned someone is going to say that the
because you say these things, someone else is going to
declare that the content of the [v]printk_emit bits is
effectively an ABI (inviolate and immutable) like the
seq_ functions.  I think that'd make changing any of the
logging much more difficult and should be avoided.

> - 100% message integrity of structured messages, and single line
>   prints, and if only one continuation line user prints at a time.
>   We never mix continuation users with full line users, like the
>   old buffer did.
> - very reliable continuation line prints, because of the buffering.
>   The only race that can still happen is several cont users racing
>   against each other, which is not too likely

It's hard to say that it's not too likely.  I think it
depends on cpu count.  More cpus, more likely.

Still, it's decidedly better than it was.

> - 100% granularity at line level during userspace buffer access,
>   crash dumping; we never copy around half or overwritten lines,
>   like the old buffer
> - the ring buffer prunes only entire messages not just the half
>   of a line like the old byte buffer
> - sequence numbers allow us to track the state of the read and write
>   position in the buffer, so we never copy in-the-meantime already
>   overwritten messages around
> - sequence numbers which allow userspace to reconnect to the old reading
>   position and process only new messages, and find if messages got
>   overwritten
> - support for multiple concurrent readers with live update of the kernel
>   log stream

Good features list and it was well implemented too.

I think the uses of the direct emit model should simply
be updated to full lines as you suggested.  There are not
too many files that need touching.

Re: [PATCH] printk: Add printk_flush() to force buffered text to console

[Kay Sievers]

On Sat, Jun 23, 2012 at 5:28 PM, Joe Perches <joe@perches.com> wrote:

>> - proper device identifiers attached to a message, which allows
>>   tools for the first time to know the contexts of the kernel messages
>
> I think this is not particularly true nor really useful at
> present and the [v]printk_emit parts should be removed
> until a the benefit of such a capability more proven.

We track all 'interesting' devices in userspace. So you can ask the
system management about a mountpoint or a network interface and it
will show all messages that got emitted during that bootup from the
underlying devices in that context. With it's udev integration we can
also include all the userspace data about the devices and walk up the
parent devices and include the parent device information into the
output.

For example, you ask for the state of a mountpoint and the system will
return you all messages that got emitted from the underlying block
devices/disks, then you can broaden the match and include all messages
from the storage host controller where the disks are connected, and so
on.

Similarly you can efficiently retrieve the logged messages for a
network interface, including the parent device, which is usually a PCI
card.

That's just how stuff should work today, and the consumer side of it
is almost ready to ship, it's just the reliable device identifier in
the kernel log that is missing today, and which we wait for, to be
generally available.

The idea is similar how you can ask today for "give me all log
messages of a certain service (note, not a PID):
  https://plus.google.com/108087225644395745666/posts/iuFEgBZT3co

The whole point of attaching the context, where a message was
generated from, in a sane format, is to replace the former unparsable
and unrecognizable prefixes like:
  cdc_acm 2-1.4:1.1: ...
  iwlwifi 0000:03:00.0: ...
  usb usb2: ...

which now are:
   SUBSYSTEM=usb
   DEVICE=+usb:2-1.4:1.1

   SUBSYSTEM=pci
   DEVICE=+pci:0000:03:00.0

   SUBSYSTEM=usb
   DEVICE=c189:1

>From that angle, this just makes things possible which have always
been intended to be possible, but which have just been insufficiently
implemented for dev_printk().

> I'm still concerned someone is going to say that the
> because you say these things, someone else is going to
> declare that the content of the [v]printk_emit bits is
> effectively an ABI (inviolate and immutable) like the
> seq_ functions.  I think that'd make changing any of the
> logging much more difficult and should be avoided.

Nothing should really change to what we do already today, dev_printk()
was supposed to be recognizable, it just wasn't good enough, it wasn't
intentionally insufficiently implemented.

We do not give the messages texts any more meaning than they already
carry, we can just properly *filter* for them. The importance or not
of the actual text stays pretty much the same. People today already
run magic regexes on the kernel log to guess what's happened in there,
and the attached context to allow reliable filtering and
identification does not change it.

What we did in the old logging was to throw away all of the context
the kernel has at logging time, log the pure text with a pretty much
unrecognizable prefix, and later start guessing games to restore the
context again. That's really a pretty amateurish way of doing
software. Tools in "the stuff mostly works, or otherwise humans can
probably make sense of it" category might be fine or even unavoidable
in some areas of software development, but it is surely not how the
basic building blocks of an operating system should work today. :)

Kay