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:   Mon, 10 May 2021 20:16:55 +0900
From:   Sergey Senozhatsky <senozhatsky@chromium.org>
To:     John Ogness <john.ogness@linutronix.de>
Cc:     Petr Mladek <pmladek@suse.com>,
        Sergey Senozhatsky <senozhatsky@chromium.org>,
        Luo Jiaxing <luojiaxing@huawei.com>,
        sergey.senozhatsky@gmail.com, rostedt@goodmis.org,
        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: <YJkWJ7OCzFM7m4OU@google.com>
References: <1620288026-5373-1-git-send-email-luojiaxing@huawei.com>
 <YJPxj83F1sBjHHAE@alley>
 <YJP4F1UIt/eRZ96s@google.com>
 <YJP5MnkJ8pJevXM6@google.com>
 <YJVsgPc66lhaAUN0@alley>
 <YJjuRV57eO3Pp/bp@google.com>
 <YJkIK9cyHr46UAFP@alley>
 <871raeop5q.fsf@jogness.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <871raeop5q.fsf@jogness.linutronix.de>
Precedence: bulk

On (21/05/10 12:32), John Ogness wrote:
> On 2021-05-10, Petr Mladek <pmladek@suse.com> wrote:
> > The current plan is to move console work to kthreads (separate
> > preemptive context). Using IRQ is a complete opposite way.
> >
> > There is always the fight between getting the messages out as soon
> > as possible and the risk of breaking the system (softlockups,
> > deadlocks).
> >
> > The kthread approach reduces the risk of system breakage to a bare
> > minimum. The price is that some messages might never reach console.
> > There is finally a consensus to give it a try. If it fails, we might
> > start looking for alternatives again.
> 
> +1
> 
> I think it is clear that any such fixups will disappear once
> atomic-consoles and console printing kthreads arrive.

Yes, hopefully.

> That doesn't mean we should ignore the fixups.

Well, that also doesn't mean that we should not discuss the fixups.
And there seems to be some sort of taboo on discussions.

> We just need to decide if it is a real problem that needs our
> immediate attention, thus warranting a fixup in the current implementation.

That's a good point.

> I can see the suspend/resume issue might be a real problem. If this
> should be addressed now, I would support Petr's patch, forcing the
> backlog to be printed in the preemptible resuming context. But let's
> just keep it a suspend/resume fixup. I do not think we want to start
> playing with how console_unlock() behaves.

And yes again. If console suspend/resume is a problem then something
superficially about suspend/resume can be done. System wide API that
makes printk behave either like "old" or like "new" one depending on
some flags is slightly opposite to "keep printk simple" intention. IMHO