On Wed 09-10-19 09:06:42, Qian Cai wrote: [...] > https://lore.kernel.org/linux-mm/1570460350.5576.290.camel@xxxxxx/ > > [ 297.425964] -> #1 (&port_lock_key){-.-.}: > [ 297.425967] __lock_acquire+0x5b3/0xb40 > [ 297.425967] lock_acquire+0x126/0x280 > [ 297.425968] _raw_spin_lock_irqsave+0x3a/0x50 > [ 297.425969] serial8250_console_write+0x3e4/0x450 > [ 297.425970] univ8250_console_write+0x4b/0x60 > [ 297.425970] console_unlock+0x501/0x750 > [ 297.425971] vprintk_emit+0x10d/0x340 > [ 297.425972] vprintk_default+0x1f/0x30 > [ 297.425972] vprintk_func+0x44/0xd4 > [ 297.425973] printk+0x9f/0xc5 > [ 297.425974] register_console+0x39c/0x520 > [ 297.425975] univ8250_console_init+0x23/0x2d > [ 297.425975] console_init+0x338/0x4cd > [ 297.425976] start_kernel+0x534/0x724 > [ 297.425977] x86_64_start_reservations+0x24/0x26 > [ 297.425977] x86_64_start_kernel+0xf4/0xfb > [ 297.425978] secondary_startup_64+0xb6/0xc0 > > where the report again show the early boot call trace for the locking > dependency, > > console_owner --> port_lock_key > > but that dependency clearly not only happen in the early boot. Can you provide an example of the runtime dependency without any early boot artifacts? Because this discussion really doens't make much sense without a clear example of a _real_ lockdep report that is not a false possitive. All of them so far have been concluded to be false possitive AFAIU. -- Michal Hocko SUSE Labs
