On 2023-06-26 12:48:31 [+0200], Peter Zijlstra wrote: > > Don't be like that... just hate on prink like the rest of us. In fact, > i've been patching out the actual printk code for years because its > unusable garbage. :) > Will this actually still be a problem once all the fancy printk stuff > lands? That shouldn't do synchronous prints except to 'atomic' consoles > by default IIRC. The fancy printk stuff should have synchronous printing in emergency situations and threaded printing by default. But then I hear John saying that there might be push back because atomic consoles may not be available everywhere… Anyway, the requirement for the deadlock to trigger, that Tetsuo Handa is concerned here: - lockdep enabled - console and tty in use. - tty_insert_flip_string_and_push_buffer() on one CPU with tty_port::lock acquired followed with a memory allocation blocking on read_seqbegin(&zonelist_update_seq) due the writer - memory hotplug => __build_all_zonelists() acquiring write_seqlock(&zonelist_update_seq) and now lockdep creates a splat. This is accounted for if the lockdep annotation comes first (1/2 of the series). But the unlock annotation of the seq unlock operation may still create a splat so a possibility for a deadlock remains. The requirement is _high_ and it hardly justifies ugly code. Sebastian
