On (20/11/18 11:46), Sergey Senozhatsky wrote:
[..]
> > Because I'm not sure where the xmit_lock is taken while holding the
> > target_list_lock.
>
> I don't see where does this happen. It seems to me that the report
> is not about broken locking order, but more about:
> - soft-irq can be preempted (while holding _xmit_lock) by a hardware
> interrupt, that will attempt to acquire the same _xmit_lock lock.
>
> CPU0
> <<soft IRQ>>
> virtnet_poll_tx()
> __netif_tx_lock()
> spin_lock(_xmit_lock)
> <<hard IRQ>>
> add_interrupt_randomness()
> crng_fast_load()
> printk()
> call_console_drivers()
> spin_lock_irqsave(&target_list_lock)
> spin_lock(_xmit_lock);
>
> Does this make sense?
Hmm, lockdep says something similar, but there are 2 printk()
happening - both on local and remote CPUs.
[ 21.149564] CPU0 CPU1
[ 21.149565] ---- ----
[ 21.149566] lock(_xmit_ETHER#2);
[ 21.149569] local_irq_disable();
[ 21.149570] lock(console_owner);
[ 21.149572] lock(target_list_lock);
[ 21.149575] <Interrupt>
[ 21.149576] lock(console_owner);
This CPU0 lock(_xmit_ETHER#2) -> hard IRQ -> lock(console_owner) is
basically
soft IRQ -> lock(_xmit_ETHER#2) -> hard IRQ -> printk()
Then CPU1 spins on xmit, which is owned by CPU0, CPU0 spins on
console_owner, which is owned by CPU1?
A quick-and-dirty idea (it doesn't fix the lockdep report) - can we
add some sort of max_loops variable to console_trylock_spinning(),
so that it will not spin forever in `while (READ_ONCE(console_waiter))`
waiting for a console_owner to pass the lock?
-ss
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
