From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754478AbdIFCRU (ORCPT ); Tue, 5 Sep 2017 22:17:20 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:37766 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751333AbdIFCRS (ORCPT ); Tue, 5 Sep 2017 22:17:18 -0400 X-Google-Smtp-Source: ADKCNb63DlY+MBkRza1Kf2h+DYKsPHGk/mw92W0eMpf0Ht13nLBKPN9o/4+QNK1K0d4vylIG3bkWIA== Date: Wed, 6 Sep 2017 11:14:26 +0900 From: Sergey Senozhatsky To: Steven Rostedt Cc: Sergey Senozhatsky , Linus Torvalds , Joe Perches , Sergey Senozhatsky , Pavel Machek , Petr Mladek , Jan Kara , Andrew Morton , Jiri Slaby , Andreas Mohr , Tetsuo Handa , Linux Kernel Mailing List Subject: Re: printk: what is going on with additional newlines? Message-ID: <20170906021426.GA6773@jagdpanzerIV.localdomain> References: <20170829195013.5048dc42@gandalf.local.home> <20170830010348.GB654@jagdpanzerIV.localdomain> <20170829211046.74644c8a@gandalf.local.home> <20170901131656.GA468@tigerII.localdomain> <1504287133.2361.11.camel@perches.com> <20170904052246.GB28534@jagdpanzerIV.localdomain> <20170905105454.29160c5e@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170905105454.29160c5e@gandalf.local.home> User-Agent: Mutt/1.9.0 (2017-09-02) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (09/05/17 10:54), Steven Rostedt wrote: > On Mon, 4 Sep 2017 14:22:46 +0900 > Sergey Senozhatsky wrote: > > > like I said in another email, printk-safe buffer > > is per-CPU and is also used for actual printk-safe, hence it must be > > used with local IRQs disabled when we "borrow" the buffer for pr_line > > (disabled preemption is not enough due to possible IRQ printk-safe > > print out). this can be a bit annoying. > > You can do what I did with trace_printk(). I have a buffer per context. > Then you only need to use preempt_disable() to do the print. That is, > trace_printk() has 4 buffers: > > 1. Normal context > 2. softirq context > 3. irq context > 4. NMI context thanks. looks interesting. > It determines which context it is in, disables preemption, and uses the > corresponding buffer. This way I don't need to worry about being > preempted by an interrupt or NMI. > > Grant it, it does make the memory needed 4x bigger. yep. that's a concern. buffered printk must come with a sound number of users in this case. otherwise people will just see a massive bump (x2) in memory usage for no particular reason. > I have an array of 4 buffers, and the following code: > > static char *get_trace_buf(void) > { > struct trace_buffer_struct *buffer = this_cpu_ptr(trace_percpu_buffer); > > if (!buffer || buffer->nesting >= 4) > return NULL; > > return &buffer->buffer[buffer->nesting++][0]; > } > > Hmm, I probably need to add a "barrier()" before the return, or use a > this_cpu_inc() on nesting. As long as the nesting variable is updated > before the return of the buffer being used, then everything is fine. > Because we have: > > static void put_trace_buf(void) > { > this_cpu_dec(trace_percpu_buffer->nesting); > } > > And anything that preempts this call will have returned it back to its > original state before returning. there is a tiny-tiny-tiny chance of losing some very specific messages from the top most context. consider the following trace_printk("fat fingers %o\n", 100); from the NMI (nesting 3) context. vscnprintf() must WARN_ONCE(1, "Unsupported flags modifier: %c\n", fmt[1]); which will be lost - we are above the nesting limit buffer->nesting >= 4. // vscnprintf()->... has several more recursion entry points. -ss