Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 7 May 2021 18:13:41 +0200
From:   Petr Mladek <pmladek@suse.com>
To:     Sergey Senozhatsky <senozhatsky@chromium.org>
Cc:     Luo Jiaxing <luojiaxing@huawei.com>, sergey.senozhatsky@gmail.com,
        rostedt@goodmis.org, john.ogness@linutronix.de,
        linux-kernel@vger.kernel.org, linuxarm@huawei.com,
        bobo.shaobowang@huawei.com
Subject: Re: [PATCH] printk: stop spining waiter when console resume to flush
 prb
Message-ID: <YJVnNQ7RGvx9JKxV@alley>
References: <1620288026-5373-1-git-send-email-luojiaxing@huawei.com>
 <YJPxj83F1sBjHHAE@alley>
 <YJP4F1UIt/eRZ96s@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YJP4F1UIt/eRZ96s@google.com>
Precedence: bulk

On Thu 2021-05-06 23:07:19, Sergey Senozhatsky wrote:
> Thanks for Cc-ing Petr
> 
> On (21/05/06 15:39), Petr Mladek wrote:
> > 
> > Many printk messages might get accumulated when consoles were suspended.
> > They are proceed when console_unlock() is called in resume_console().
> > 
> > The possibility to pass the console lock owner was added to reduce the risk
> > of softlockup when too many messages were handled in an atomic context.
> > 
> > Now, resume_console() is always in a preemptible context that is safe
> > to handle all accumulated messages. The possibility to pass the console
> > lock owner actually makes things worse. The new owner might be in an atomic
> > context and might cause softlockup when processing all messages accumulated
> > when the console was suspended.
> > 
> > Create new console_unlock_preemptible() that will not allow to pass
> > the console lock owner. As a result, all accumulated messages will
> > be proceed in the safe preemptible process.
> 
> If we have a lot of pending messages in the logbuf, then there is
> something chatty - some context (task, irq) or maybe several contexts.
> And those contexts can continue adding messages, while we print them
> _exclusively_ from preemptible context only. without ever throttling down
> printk() callers - something that console_owner spinning and handover
> does for us. And those printk() callers can even preempt
> console_unlock_preemptible() and cause delays and lost messages.

Luo, please, correct me if I am wrong.

This patch a about one well defined scenario. The messages are
accumulated between suspend_console() and resume_console().
It is "small" part of the system hibernation. And we need
to get them out now. There might be many if something special
was debugged.

I am pretty sure that Luo did not see any flood of messages:

   + Flood in more contexts would be balanced by switching
     the console_owner.

   + Flood in one context would be naturally throttled because
     this context will become the console_owner.

In each case, these messages would be generated after
console_resume(). Luo's original patch was explicitly talking
about messages accumulated during the suspend.

Luo, could you please provide some log showing the problem?

Best Regards,
Petr