mirror of
https://git.proxmox.com/git/mirror_zfs.git
synced 2024-12-27 11:29:36 +03:00
ede0bdffb6
When HAVE_MUTEX_OWNER is defined and we are directly accessing mutex->owner treat is as volative with the ACCESS_ONCE() helper. Without this you may get a stale cached value when accessing it from different cpus. This can result in incorrect behavior from mutex_owned() and mutex_owner(). This is not a problem for the !HAVE_MUTEX_OWNER case because in this case all the accesses are covered by a spin lock which similarly gaurentees we will not be accessing stale data. Secondly, check CONFIG_SMP before allowing access to mutex->owner. I see that for non-SMP setups the kernel does not track the owner so we cannot rely on it. Thirdly, check CONFIG_MUTEX_DEBUG when this is defined and the HAVE_MUTEX_OWNER is defined surprisingly the mutex->owner will not be cleared on mutex_exit(). When this is the case the SPL needs to make sure to do it to ensure MUTEX_HELD() behaves as expected or you will certainly assert in mutex_destroy(). Finally, improve the mutex regression tests. For mutex_owned() we now minimally check that it behaves correctly when checked from the owner thread or the non-owner thread. This subtle behaviour has bit me before and I'd like to catch it early next time if it reappears. As for mutex_owned() regression test additonally verify that mutex->owner is always cleared on mutex_exit(). |
||
|---|---|---|
| .. | ||
| .gitignore | ||
| Makefile.in | ||
| splat-atomic.c | ||
| splat-condvar.c | ||
| splat-cred.c | ||
| splat-ctl.c | ||
| splat-generic.c | ||
| splat-internal.h | ||
| splat-kmem.c | ||
| splat-kobj.c | ||
| splat-list.c | ||
| splat-mutex.c | ||
| splat-random.c | ||
| splat-rwlock.c | ||
| splat-taskq.c | ||
| splat-thread.c | ||
| splat-time.c | ||
| splat-vnode.c | ||