Messages in this thread | | | Date | Wed, 30 Mar 2016 15:25:49 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable |
| |
On Mon, Feb 29, 2016 at 01:58:17PM +0100, Michal Hocko wrote: > @@ -215,16 +216,34 @@ void __sched __down_write(struct rw_semaphore *sem) > */ > if (sem->count == 0) > break; > - set_task_state(tsk, TASK_UNINTERRUPTIBLE); > + set_task_state(tsk, state); > raw_spin_unlock_irqrestore(&sem->wait_lock, flags); > schedule(); > + if (signal_pending_state(state, current)) { > + ret = -EINTR; > + raw_spin_lock_irqsave(&sem->wait_lock, flags); > + goto out; > + } > raw_spin_lock_irqsave(&sem->wait_lock, flags); > } > /* got the lock */ > sem->count = -1;
> @@ -487,20 +488,38 @@ struct rw_semaphore __sched *rwsem_down_write_failed(struct rw_semaphore *sem) > /* Block until there are no active lockers. */ > do { > schedule(); > - set_current_state(TASK_UNINTERRUPTIBLE); > + if (signal_pending_state(state, current)) { > + raw_spin_lock_irq(&sem->wait_lock); > + ret = ERR_PTR(-EINTR); > + goto out; > + } > + set_current_state(state); > } while ((count = sem->count) & RWSEM_ACTIVE_MASK); > > raw_spin_lock_irq(&sem->wait_lock); > } > __set_current_state(TASK_RUNNING);
Why is the signal_pending_state() test _after_ the call to schedule() and before the 'trylock'.
__mutex_lock_common() has it before the call to schedule and after the 'trylock'.
The difference is that rwsem will now respond to the KILL and return -EINTR even if the lock is available, whereas mutex will acquire it and ignore the signal (for a little while longer).
Neither is wrong per se, but I feel all the locking primitives should behave in a consistent manner in this regard.
| |