mirror of
https://git.proxmox.com/git/mirror_zfs.git
synced 2025-10-26 18:05:04 +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(). |
||
|---|---|---|
| cmd | ||
| config | ||
| include | ||
| lib | ||
| module | ||
| patches | ||
| scripts | ||
| .gitignore | ||
| AUTHORS | ||
| autogen.sh | ||
| ChangeLog | ||
| configure | ||
| configure.ac | ||
| COPYING | ||
| DISCLAIMER | ||
| INSTALL | ||
| Makefile.am | ||
| Makefile.in | ||
| META | ||
| spl_config.h.in | ||
| spl-modules.spec.in | ||
| spl.spec.in | ||