All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <swboyd@chromium.org>
To: Kees Cook <keescook@chromium.org>,
	Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Cc: Anton Vorontsov <anton@enomsg.org>,
	Colin Cross <ccross@android.com>, Tony Luck <tony.luck@intel.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Matthias Kaehlcke <mka@chromium.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	Douglas Anderson <dianders@chromium.org>
Subject: Re: [PATCH] pstore: Fix printing of duplicate boot messages to console
Date: Wed, 29 Jan 2020 22:30:57 -0800	[thread overview]
Message-ID: <5e327822.1c69fb81.80136.dfc1@mx.google.com> (raw)
In-Reply-To: <202001271525.E6EB4FDD6@keescook>

Quoting Kees Cook (2020-01-27 15:27:33)
> On Thu, Jan 23, 2020 at 09:30:31PM +0530, Sai Prakash Ranjan wrote:
> > Since commit f92b070f2dc8 ("printk: Do not miss new messages
> > when replaying the log"), CON_PRINTBUFFER flag causes the
> > duplicate boot messages to be printed on the console when
> > PSTORE_CONSOLE and earlycon (boot console) is enabled.
> > Pstore console registers to boot console when earlycon is
> > enabled during pstore_register_console as a part of ramoops
> > initialization in postcore_initcall and the printk core
> > checks for CON_PRINTBUFFER flag and replays the log buffer
> > to registered console (in this case pstore console which
> > just registered to boot console) causing duplicate messages
> > to be printed. Remove the CON_PRINTBUFFER flag from pstore
> > console since pstore is not concerned with the printing of
> > buffer to console but with writing of the buffer to the
> > backend.
> 
> I agree this patch isn't the solution, but I'm trying to understand
> where better logic could be added. Is the issue that printk sees both
> earlycon and CON_PRINTBUFFER active? Can we add a new CON_* flag that
> means "not actually printing anything"? (Or maybe a new flag for
> non-printing to replace CON_PRINTBUFFER that lets pstore still work?)
> 

This seems to be fixed by commit def97da13651 ("printk: fix
exclusive_console replaying"). I think there's nothing to do.


WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <swboyd@chromium.org>
To: Kees Cook <keescook@chromium.org>,
	Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Cc: Tony Luck <tony.luck@intel.com>,
	linux-arm-msm@vger.kernel.org, Anton Vorontsov <anton@enomsg.org>,
	linux-kernel@vger.kernel.org,
	Douglas Anderson <dianders@chromium.org>,
	Matthias Kaehlcke <mka@chromium.org>,
	Colin Cross <ccross@android.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] pstore: Fix printing of duplicate boot messages to console
Date: Wed, 29 Jan 2020 22:30:57 -0800	[thread overview]
Message-ID: <5e327822.1c69fb81.80136.dfc1@mx.google.com> (raw)
In-Reply-To: <202001271525.E6EB4FDD6@keescook>

Quoting Kees Cook (2020-01-27 15:27:33)
> On Thu, Jan 23, 2020 at 09:30:31PM +0530, Sai Prakash Ranjan wrote:
> > Since commit f92b070f2dc8 ("printk: Do not miss new messages
> > when replaying the log"), CON_PRINTBUFFER flag causes the
> > duplicate boot messages to be printed on the console when
> > PSTORE_CONSOLE and earlycon (boot console) is enabled.
> > Pstore console registers to boot console when earlycon is
> > enabled during pstore_register_console as a part of ramoops
> > initialization in postcore_initcall and the printk core
> > checks for CON_PRINTBUFFER flag and replays the log buffer
> > to registered console (in this case pstore console which
> > just registered to boot console) causing duplicate messages
> > to be printed. Remove the CON_PRINTBUFFER flag from pstore
> > console since pstore is not concerned with the printing of
> > buffer to console but with writing of the buffer to the
> > backend.
> 
> I agree this patch isn't the solution, but I'm trying to understand
> where better logic could be added. Is the issue that printk sees both
> earlycon and CON_PRINTBUFFER active? Can we add a new CON_* flag that
> means "not actually printing anything"? (Or maybe a new flag for
> non-printing to replace CON_PRINTBUFFER that lets pstore still work?)
> 

This seems to be fixed by commit def97da13651 ("printk: fix
exclusive_console replaying"). I think there's nothing to do.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-01-30  6:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-23 16:00 [PATCH] pstore: Fix printing of duplicate boot messages to console Sai Prakash Ranjan
2020-01-23 16:00 ` Sai Prakash Ranjan
2020-01-23 19:49 ` Stephen Boyd
2020-01-23 19:49   ` Stephen Boyd
2020-01-24  8:48   ` Sai Prakash Ranjan
2020-01-24  8:48     ` Sai Prakash Ranjan
2020-01-27 23:27 ` Kees Cook
2020-01-27 23:27   ` Kees Cook
2020-01-30  6:30   ` Stephen Boyd [this message]
2020-01-30  6:30     ` Stephen Boyd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5e327822.1c69fb81.80136.dfc1@mx.google.com \
    --to=swboyd@chromium.org \
    --cc=anton@enomsg.org \
    --cc=ccross@android.com \
    --cc=dianders@chromium.org \
    --cc=joel@joelfernandes.org \
    --cc=keescook@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mka@chromium.org \
    --cc=saiprakash.ranjan@codeaurora.org \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.