Pull locking fixes from Thomas Gleixner: "Two fixes for the locking subsystem: - Prevent an unconditional interrupt enable in a futex helper function which can be called from contexts which expect interrupts to stay disabled across the call - Don't modify lockdep chain keys in the validation process as that causes chain inconsistency" * tag 'locking-urgent-2020-11-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: lockdep: Avoid to modify chain keys in validate_chain() futex: Don't enable IRQs unconditionally in put_pi_state()
Showing the changes to kernel (2 of 2 files). Show all
Unified · Split
| @@ -788,8 +788,9 @@ static void put_pi_state(struct futex_pi_state *pi_state) · 787 unmodified lines | ||
| 788 | 788 | */ |
| 789 | 789 | if (pi_state->owner) { |
| 790 | 790 | struct task_struct *owner; |
| 791 | + unsigned long flags; | |
| 791 | 792 | |
| 792 | − raw_spin_lock_irq(&pi_state->pi_mutex.wait_lock); | |
| 793 | + raw_spin_lock_irqsave(&pi_state->pi_mutex.wait_lock, flags); | |
| 793 | 794 | owner = pi_state->owner; |
| 794 | 795 | if (owner) { |
| 795 | 796 | raw_spin_lock(&owner->pi_lock); |
| @@ -797,7 +798,7 @@ static void put_pi_state(struct futex_pi_state *pi_state) · 1 unmodified line | ||
| 797 | 798 | raw_spin_unlock(&owner->pi_lock); |
| 798 | 799 | } |
| 799 | 800 | rt_mutex_proxy_unlock(&pi_state->pi_mutex, owner); |
| 800 | − raw_spin_unlock_irq(&pi_state->pi_mutex.wait_lock); | |
| 801 | + raw_spin_unlock_irqrestore(&pi_state->pi_mutex.wait_lock, flags); | |
| 801 | 802 | } |
| 802 | 803 | |
| 803 | 804 | if (current->pi_state_cache) { |
| @@ -2765,7 +2765,9 @@ print_deadlock_bug(struct task_struct *curr, struct held_lock *prev, · 2764 unmodified lines | ||
| 2765 | 2765 | * (Note that this has to be done separately, because the graph cannot |
| 2766 | 2766 | * detect such classes of deadlocks.) |
| 2767 | 2767 | * |
| 2768 | − * Returns: 0 on deadlock detected, 1 on OK, 2 on recursive read | |
| 2768 | + * Returns: 0 on deadlock detected, 1 on OK, 2 if another lock with the same | |
| 2769 | + * lock class is held but nest_lock is also held, i.e. we rely on the | |
| 2770 | + * nest_lock to avoid the deadlock. | |
| 2769 | 2771 | */ |
| 2770 | 2772 | static int |
| 2771 | 2773 | check_deadlock(struct task_struct *curr, struct held_lock *next) |
| @@ -2788,7 +2790,7 @@ check_deadlock(struct task_struct *curr, struct held_lock *next) · 16 unmodified lines | ||
| 2788 | 2790 | * lock class (i.e. read_lock(lock)+read_lock(lock)): |
| 2789 | 2791 | */ |
| 2790 | 2792 | if ((next->read == 2) && prev->read) |
| 2791 | − return 2; | |
| 2793 | + continue; | |
| 2792 | 2794 | |
| 2793 | 2795 | /* |
| 2794 | 2796 | * We're holding the nest_lock, which serializes this lock's |
| @@ -3592,16 +3594,13 @@ static int validate_chain(struct task_struct *curr, · 797 unmodified lines | ||
| 3592 | 3594 | |
| 3593 | 3595 | if (!ret) |
| 3594 | 3596 | return 0; |
| 3595 | − /* | |
| 3596 | − * Mark recursive read, as we jump over it when | |
| 3597 | − * building dependencies (just like we jump over | |
| 3598 | − * trylock entries): | |
| 3599 | − */ | |
| 3600 | − if (ret == 2) | |
| 3601 | − hlock->read = 2; | |
| 3602 | 3597 | /* |
| 3603 | 3598 | * Add dependency only if this lock is not the head |
| 3604 | − * of the chain, and if it's not a secondary read-lock: | |
| 3599 | + * of the chain, and if the new lock introduces no more | |
| 3600 | + * lock dependency (because we already hold a lock with the | |
| 3601 | + * same lock class) nor deadlock (because the nest_lock | |
| 3602 | + * serializes nesting locks), see the comments for | |
| 3603 | + * check_deadlock(). | |
| 3605 | 3604 | */ |
| 3606 | 3605 | if (!chain_head && ret != 2) { |
| 3607 | 3606 | if (!check_prevs_add(curr, hlock)) |