On 04/09/2018 07:20 AM, Oleg Nesterov wrote: > On 04/04, Waiman Long wrote: >> --- a/kernel/locking/percpu-rwsem.c >> +++ b/kernel/locking/percpu-rwsem.c >> @@ -179,8 +179,10 @@ void percpu_up_write(struct percpu_rw_semaphore *sem) >> >> /* >> * Release the write lock, this will allow readers back in the game. >> + * percpu_up_write() may be called from a task different from the one >> + * taking the lock. >> */ >> - up_write(&sem->rw_sem); >> + up_write_non_owner(&sem->rw_sem); >> >> /* >> * Once this completes (at least one RCU-sched grace period hence) the >> diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c >> index 30465a2..140d5ef 100644 >> --- a/kernel/locking/rwsem.c >> +++ b/kernel/locking/rwsem.c >> @@ -222,4 +222,17 @@ void up_read_non_owner(struct rw_semaphore *sem) >> >> #endif >> >> +#ifdef CONFIG_DEBUG_RWSEMS >> +/* >> + * release a write lock from a different task >> + */ >> +void up_write_non_owner(struct rw_semaphore *sem) >> +{ >> + rwsem_release(&sem->dep_map, 1, _RET_IP_); >> + DEBUG_RWSEMS_WARN_ON(!sem->owner || (sem->owner == RWSEM_READER_OWNED)); >> >> + rwsem_clear_owner(sem); >> + __up_write(sem); >> +} > Hmm. Can you look at lockdep_sb_freeze_release() and lockdep_sb_freeze_acquire()? These 2 functions are there to deal with the lockdep code. > At first glance, it would be much better to set sem->owner = current in > percpu_rwsem_acquire(), no? The primary purpose of the owner field is to enable optimistic spinning to improve locking performance. So it needs to be set during an up_write() call. My rwsem debug patch does use it also to check for consistency in the use of lock/unlock call. Anyway, I don't think it is right to set it again in percpu_rwsem_acquire() if there is no guarantee that the task that call percpu_rwsem_acquire will be the one that will do the unlock. I am wondering if it makes sense to do optimistic spinning in the case of percpu_rwsem where the unlocker may be a different task. We could set a special code for writer owned lock, but don't do optimistic spinning in this case. Cheers, Longman