Hi,
I find this function __up_writer refering to an anonymous a writer? How does it occur?
```
// kernel/locking/rwsem.c
static inline void __up_write(struct rw_semaphore *sem)
{
long tmp;
DEBUG_RWSEMS_WARN_ON(sem->magic != sem, sem);
/*
* sem->owner may differ from current if the ownership is transferred
* to an anonymous writer by setting the RWSEM_NONSPINNABLE bits.
*/
DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) &&
!rwsem_test_oflags(sem, RWSEM_NONSPINNABLE), sem); <------------------ is it necessary?
preempt_disable();
rwsem_clear_owner(sem);
tmp = atomic_long_fetch_add_release(-RWSEM_WRITER_LOCKED, &sem->count);
if (unlikely(tmp & RWSEM_FLAG_WAITERS))
rwsem_wake(sem);
preempt_enable();
}
```
{
long tmp;
DEBUG_RWSEMS_WARN_ON(sem->magic != sem, sem);
/*
* sem->owner may differ from current if the ownership is transferred
* to an anonymous writer by setting the RWSEM_NONSPINNABLE bits.
*/
DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) &&
!rwsem_test_oflags(sem, RWSEM_NONSPINNABLE), sem); <------------------ is it necessary?
preempt_disable();
rwsem_clear_owner(sem);
tmp = atomic_long_fetch_add_release(-RWSEM_WRITER_LOCKED, &sem->count);
if (unlikely(tmp & RWSEM_FLAG_WAITERS))
rwsem_wake(sem);
preempt_enable();
}
```
I do a search by using `git blame` and find it's added in this commit 02f1082b003a0cd48f48f12533d969cdbf1c2b63,
and in this commit d7d760efad70c7a030725499bf9f342f04af24dd, it refers to below situation that can have an anonymous writer:
> There are use cases where a rwsem can be acquired by one task, but
> released by another task. In thess cases, optimistic spinning may need
> to be disabled. One example will be the filesystem freeze/thaw code
> where the task that freezes the filesystem will acquire a write lock
> on a rwsem and then un-owns it before returning to userspace. Later on,
> another task will come along, acquire the ownership, thaw the filesystem
> and release the rwsem.
>
> Bit 0 of the owner field was used to designate that it is a reader
> owned rwsem. It is now repurposed to mean that the owner of the rwsem
> is not known. If only bit 0 is set, the rwsem is reader owned. If bit
> 0 and other bits are set, it is writer owned with an unknown owner.
> One such value for the latter case is (-1L). So we can set owner to 1 for
> reader-owned, -1 for writer-owned. The owner is unknown in both cases.
>
> To handle transfer of rwsem ownership, the higher level code should
> set the owner field to -1 to indicate a write-locked rwsem with unknown
> owner. Optimistic spinning will be disabled in this case.
>
> Once the higher level code figures who the new owner is, it can then
> set the owner field accordingly.
> released by another task. In thess cases, optimistic spinning may need
> to be disabled. One example will be the filesystem freeze/thaw code
> where the task that freezes the filesystem will acquire a write lock
> on a rwsem and then un-owns it before returning to userspace. Later on,
> another task will come along, acquire the ownership, thaw the filesystem
> and release the rwsem.
>
> Bit 0 of the owner field was used to designate that it is a reader
> owned rwsem. It is now repurposed to mean that the owner of the rwsem
> is not known. If only bit 0 is set, the rwsem is reader owned. If bit
> 0 and other bits are set, it is writer owned with an unknown owner.
> One such value for the latter case is (-1L). So we can set owner to 1 for
> reader-owned, -1 for writer-owned. The owner is unknown in both cases.
>
> To handle transfer of rwsem ownership, the higher level code should
> set the owner field to -1 to indicate a write-locked rwsem with unknown
> owner. Optimistic spinning will be disabled in this case.
>
> Once the higher level code figures who the new owner is, it can then
> set the owner field accordingly.
As it mentions that at higher level, we set -1 to owner subjectively in order to do an owner migration, and I only find it's used in only
one place, i.e. percpu-rwsem in this commit 5a817641f68a6399a5fac8b7d2da67a73698ffed which has been removed in commit
7f26482a872c36b2ee87ea95b9dcd96e3d5805df.
So does it mean an anonymous writer don't exist at current kernel? should we remove the second condition in this assert check?
DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) &&
!rwsem_test_oflags(sem, RWSEM_NONSPINNABLE), sem);
!rwsem_test_oflags(sem, RWSEM_NONSPINNABLE), sem);
Thanks,
Mu
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
