mirror of
https://github.com/RGBCube/serenity
synced 2025-07-25 19:07:35 +00:00
Kernel: Resolve lock-inversion based deadlock in MasterPTY & BlockSet
MasterPTY's double buffer unblock callback would take m_slave's spinlock and then call evaluate_block_conditions() which would take BlockerSet's spinlock, while on the other hand, BlockerSet's add_blocker would take BlockerSet's spinlock, and then call should_add_blocker, which would call unblock_if_conditions_are_met, which would then call should_unblock, which will finally call MasterPTY::can_read() which will take m_slave's spinlock. Resolve this by moving the call to evaluate_block_conditions() out of the scope of m_slave's spinlock, as there's no need to hold the lock while calling it anyways.
This commit is contained in:
parent
4534a43aae
commit
ab06a76920
2 changed files with 13 additions and 4 deletions
|
@ -36,10 +36,14 @@ MasterPTY::MasterPTY(unsigned index, NonnullOwnPtr<DoubleBuffer> buffer)
|
|||
, m_buffer(move(buffer))
|
||||
{
|
||||
m_buffer->set_unblock_callback([this]() {
|
||||
m_slave.with([this](auto& slave) {
|
||||
if (slave)
|
||||
evaluate_block_conditions();
|
||||
});
|
||||
// Note that has_slave() takes and then releases the m_slave spinlock.
|
||||
// Not holding the spinlock while calling evaluate_block_conditions is legal,
|
||||
// as the call will trigger a check to see if waiters may be unblocked,
|
||||
// and if it was called spuriously (i.e. because the slave disappeared between
|
||||
// calling the unblock callback and the actual block condition evaluation),
|
||||
// the waiters will simply not unblock.
|
||||
if (has_slave())
|
||||
evaluate_block_conditions();
|
||||
});
|
||||
}
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue