Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 10 Apr 2019 17:16:10 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To:     Petr Mladek <pmladek@suse.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        Feng Tang <feng.tang@intel.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        linux-kernel@vger.kernel.org, Kees Cook <keescook@chromium.org>,
        Borislav Petkov <bp@suse.de>
Subject: Re: [PATCH 2/2] panic: Enable to print out all printk msg in buffer
Message-ID: <20190410081610.GA25962@jagdpanzerIV>
References: <1554115684-26846-1-git-send-email-feng.tang@intel.com>
 <1554115684-26846-2-git-send-email-feng.tang@intel.com>
 <20190409141430.w2fulp7jnnthojrc@pathway.suse.cz>
 <20190410015926.GC26212@jagdpanzerIV>
 <20190410080224.hmyzv2mqcjyceiw3@pathway.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190410080224.hmyzv2mqcjyceiw3@pathway.suse.cz>
User-Agent: Mutt/1.11.4 (2019-03-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On (04/10/19 10:02), Petr Mladek wrote:
> On Wed 2019-04-10 10:59:26, Sergey Senozhatsky wrote:
> > On (04/09/19 16:14), Petr Mladek wrote:
> > > We should:
> > > 
> > >    + Flush the latest messages before we replay the log.
> > 
> > Do you mean the pending messages? When we replay the log we also should
> > print "header line" and panic-cpu backtrace. So we will print panic-cpu
> > oops twice
> 
> console_flush_on_panic() is just the last resort. I believe
> that the panic header and backtrace reach the console even
> without it in most cases. Explicit flush before reply
> would just make it consistent.

I would agree. On big systems console_sem is usually unlocked (no fbcon,
no DRI, no tty writers, etc.) On desktops, laptops, and embedded device,
however, killing the kernel with console_sem locked is not entirely
uncommon.

> The panic() message is usually the most important one for debugging.
> I feel a bit uneasy that we would delay it until full replay that
> might get killed from several reasons:
>
>    + external monitoring system would force reboot
>
>    + user might realize, e.g. after 20 minutes, that the full
>      log reply was probably not worth it.
>
> I understand that people enabling this option would most likely
> wait but still. I do not see it as a big deal to repeat
> the messages.

Well, OK, this sounds reasonable. At the same time this option
depends on panic_print, which is probably debugging option anyway
and panic_print output can get a bit large and time consuming, so
maybe external monitors are not part of the picture when panic_print
is used. But no real objections; need to make sure that no one else,
except panic, will ever use that new symbol.

	-ss