Messages in this thread | | | From | John Ogness <> | Subject | Re: printk meeting at LPC | Date | Sun, 15 Sep 2019 15:47:26 +0200 |
| |
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.
> 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).
John Ogness
| |