[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen staging-4.17] x86/mm: use block_lock_speculation() in _mm_write_lock()
commit a153b8b42e9027ba3057bc7c8bf55e4d71e86ec3 Author: Jan Beulich <jbeulich@xxxxxxxx> AuthorDate: Wed Mar 27 12:28:24 2024 +0100 Commit: Jan Beulich <jbeulich@xxxxxxxx> CommitDate: Wed Mar 27 12:28:24 2024 +0100 x86/mm: use block_lock_speculation() in _mm_write_lock() I can only guess that using block_speculation() there was a leftover from, earlier on, SPECULATIVE_HARDEN_LOCK depending on SPECULATIVE_HARDEN_BRANCH. Fixes: 197ecd838a2a ("locking: attempt to ensure lock wrappers are always inline") Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 62018f08708a5ff6ef8fc8ff2aaaac46e5a60430 master date: 2024-03-18 13:53:37 +0100 --- xen/arch/x86/mm/mm-locks.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h index 3ea2d8eb03..7d6e4d2a7c 100644 --- a/xen/arch/x86/mm/mm-locks.h +++ b/xen/arch/x86/mm/mm-locks.h @@ -150,7 +150,7 @@ static always_inline void _mm_write_lock(const struct domain *d, mm_rwlock_t *l, _set_lock_level(_lock_level(d, level)); } else - block_speculation(); + block_lock_speculation(); l->recurse_count++; } -- generated by git-patchbot for /home/xen/git/xen.git#staging-4.17
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |