> On Oct 5, 2019, at 8:44 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > There is no "console_lock". Please be much more specific. > >> It is easier to avoid, >> >> zone_lock -> console_lock >> >> rather than fixing the opposite. > > "ease" isn't the main objective. A more important question is "what > makes sense". We should be able to call printk() from anywhere, any > time under any conditions. That can't be done 100% but it is the > objective. printk() should be robust and not being able to call > printk() while holding zone->lock isn't robust! > > btw, this: > > : It is unsafe to call printk() while zone->lock was held, i.e., > : > : zone->lock --> console_sem > > doesn't make a lot of sense. console_sem is a sleeping lock so > attempting to acquire it (with down()!) under spinlock is a huge bug. > Again, please be careful with the descriptions. Sorry, It is console_owner_lock.
