Messages in this thread | | | From | Daniel Vetter <> | Date | Mon, 16 Sep 2019 10:44:07 +0200 | Subject | Re: printk meeting at LPC |
| |
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
| |