[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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.