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;
MIME-Version: 1.0
References: <20190807222634.1723-1-john.ogness@linutronix.de>
 <20190904123531.GA2369@hirez.programming.kicks-ass.net> <20190905130513.4fru6yvjx73pjx7p@pathway.suse.cz>
 <20190905143118.GP2349@hirez.programming.kicks-ass.net> <alpine.DEB.2.21.1909051736410.1902@nanos.tec.linutronix.de>
 <20190905121101.60c78422@oasis.local.home> <alpine.DEB.2.21.1909091507540.1791@nanos.tec.linutronix.de>
 <87k1acz5rx.fsf@linutronix.de> <CAKMK7uHXTGKSyXgUOucNr4HSrcnBxVkkoqA=VzF4-=sZSq1MKw@mail.gmail.com>
 <87d0g18ydt.fsf@linutronix.de>
In-Reply-To: <87d0g18ydt.fsf@linutronix.de>
From:   Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon, 16 Sep 2019 10:44:07 +0200
Message-ID: <CAKMK7uH-3PqezSBTX3Xh40xyZ0o9NQFBA5gnPq70HHBGLGp8-A@mail.gmail.com>
Subject: Re: printk meeting at LPC
To:     John Ogness <john.ogness@linutronix.de>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Steven Rostedt <rostedt@goodmis.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Petr Mladek <pmladek@suse.com>,
        Andrea Parri <parri.andrea@gmail.com>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        Brendan Higgins <brendanhiggins@google.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        LKML <linux-kernel@vger.kernel.org>,
        "Theodore Ts'o" <tytso@mit.edu>, Paul Turner <pjt@google.com>,
        Prarit Bhargava <prarit@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sun, Sep 15, 2019 at 3:48 PM John Ogness <john.ogness@linutronix.de> wrote:
>
> On 2019-09-13, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >> 2. A kernel thread will be created for each registered console, each
> >> responsible for being the sole printers to their respective
> >> consoles. With this, console printing is _fully_ decoupled from
> >> printk() callers.
> >
> > Is the plan to split the console_lock up into a per-console thing? Or
> > postponed for later on?
>
> AFAICT, the only purpose for a console_lock would be to synchronize
> between the console printing kthread and some other component that wants
> to write to that same device. So a per-console console_lock should be
> the proper solution. However, I will look into the details. My main
> concerns about this are the suspend/resume logic and the code sitting
> behind /dev/console. I will share details once I've sorted it all out.
>
> >> 6. A new may-sleep function pr_flush() will be made available to wait
> >> for all previously printk'd messages to be output on all consoles
> >> before proceeding. For example:
> >>
> >>     pr_cont("Running test ABC... ");
> >>     pr_flush();
> >>
> >>     do_test();
> >>
> >>     pr_cont("PASSED\n");
> >>     pr_flush();
> >
> > Just crossed my mind: Could/should we lockdep-annotate pr_flush (take
> > a lockdep map in there that we also take around the calls down into
> > console drivers in each of the console printing kthreads or something
> > like that)? Just to avoid too many surprises when people call pr_flush
> > from within gpu drivers and wonder why it doesn't work so well.
>
> Why would it not work so well? Basically the task calling pr_flush()
> will monitor the lockless iterators of the various consoles until _all_
> have hit/passed the latest sequence number from the time of the call.

Classic deadlock like the below: Some thread:

mutex_lock(A);
pr_flush();
mutex_unlock(A);

And in the normal console write code also needs do to mutex_lock(A);
mutex_unlock(A); somewhere.

> > Although with this nice plan we'll take the modeset paths fully out of
> > the printk paths (even for normal outputs) I hope, so should be a lot
> > more reasonable.
>
> You will be running in your own preemptible kthread, so any paths you
> take should be safe.
>
> > From gpu perspective this all sounds extremely good and first
> > realistic plan that might lead us to an actually working bsod on
> > linux.
>
> Are you planning on basing the bsod stuff on write_atomic() (which is
> used after entering an emergency state) or on the kmsg_dump facility? I
> would expect kmsg_dump might be more appropriate, unless there are
> concerns that the machine will die before getting that far (i.e. there
> is a lot that happens between when an OOPS begins and when kmsg_dumpers
> are invoked).

Yeah I think kms_dump is what the current patches use. From the fbcon
pov the important bit here is the clearly split out write_atomic, so
that we can make sure we never try to do anything stupid from special
contexts. Aside from the printing itself we also have all kinds of fun
stuff like unblank_screen() and console_unblank() currently in the
panic path still.

-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch