On 05/30/2015 12:09 AM, Sasha Levin wrote:
On 05/08/2015 09:27 AM, tip-bot for Peter Zijlstra (Intel) wrote:
Commit-ID: f233f7f1581e78fd9b4023f2e7d8c1ed89020cc9
Gitweb: http://git.kernel.org/tip/f233f7f1581e78fd9b4023f2e7d8c1ed89020cc9
Author: Peter Zijlstra (Intel)<[email protected]>
AuthorDate: Fri, 24 Apr 2015 14:56:38 -0400
Committer: Ingo Molnar<[email protected]>
CommitDate: Fri, 8 May 2015 12:37:09 +0200
locking/pvqspinlock, x86: Implement the paravirt qspinlock call patching
We use the regular paravirt call patching to switch between:
native_queued_spin_lock_slowpath() __pv_queued_spin_lock_slowpath()
native_queued_spin_unlock() __pv_queued_spin_unlock()
We use a callee saved call for the unlock function which reduces the
i-cache footprint and allows 'inlining' of SPIN_UNLOCK functions
again.
We further optimize the unlock path by patching the direct call with a
"movb $0,%arg1" if we are indeed using the native unlock code. This
makes the unlock code almost as fast as the !PARAVIRT case.
This significantly lowers the overhead of having
CONFIG_PARAVIRT_SPINLOCKS enabled, even for native code.
Signed-off-by: Peter Zijlstra (Intel)<[email protected]>
Signed-off-by: Waiman Long<[email protected]>
Signed-off-by: Peter Zijlstra (Intel)<[email protected]>
Cc: Andrew Morton<[email protected]>
Cc: Boris Ostrovsky<[email protected]>
Cc: Borislav Petkov<[email protected]>
Cc: Daniel J Blueman<[email protected]>
Cc: David Vrabel<[email protected]>
Cc: Douglas Hatch<[email protected]>
Cc: H. Peter Anvin<[email protected]>
Cc: Konrad Rzeszutek Wilk<[email protected]>
Cc: Linus Torvalds<[email protected]>
Cc: Oleg Nesterov<[email protected]>
Cc: Paolo Bonzini<[email protected]>
Cc: Paul E. McKenney<[email protected]>
Cc: Peter Zijlstra<[email protected]>
Cc: Raghavendra K T<[email protected]>
Cc: Rik van Riel<[email protected]>
Cc: Scott J Norton<[email protected]>
Cc: Thomas Gleixner<[email protected]>
Cc: [email protected]
Cc: [email protected]
Link:
http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar<[email protected]>
Hey Peter,
I'm seeing this on the latest -next kernel:
[ 8693.503262] BUG: KASan: out of bounds access in
__pv_queued_spin_lock_slowpath+0x84e/0x8c0 at addr ffffffffb9495950
[ 8693.503271] Read of size 8 by task swapper/9/0
[ 8693.503289] Address belongs to variable pv_lock_ops+0x10/0x240
I would like to clarify what the message means. pv_locks_ops + 0x10
should be the pv_wait function pointer. Also the structure should be
just 32 bytes in size and so what does the "/0x240" mean?
Cheers,
Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/