linux-kernel - Re: [tip:locking/core] locking/pvqspinlock, x86: Implement the paravirt qspinlock call patching

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 31 May 2015 14:29:42 -0400
From:	Waiman Long <waiman.long@...com>
To:	Sasha Levin <sasha.levin@...cle.com>
CC:	hpa@...or.com, doug.hatch@...com, oleg@...hat.com,
	raghavendra.kt@...ux.vnet.ibm.com, peterz@...radead.org,
	bp@...en8.de, linux-kernel@...r.kernel.org, riel@...hat.com,
	daniel@...ascale.com, scott.norton@...com,
	boris.ostrovsky@...cle.com, akpm@...ux-foundation.org,
	tglx@...utronix.de, david.vrabel@...rix.com,
	paolo.bonzini@...il.com, paulmck@...ux.vnet.ibm.com,
	torvalds@...ux-foundation.org, konrad.wilk@...cle.com,
	mingo@...nel.org, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:locking/core] locking/pvqspinlock, x86: Implement the paravirt
 qspinlock call patching

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)<peterz@...radead.org>
>> AuthorDate: Fri, 24 Apr 2015 14:56:38 -0400
>> Committer:  Ingo Molnar<mingo@...nel.org>
>> 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)<peterz@...radead.org>
>> Signed-off-by: Waiman Long<Waiman.Long@...com>
>> Signed-off-by: Peter Zijlstra (Intel)<peterz@...radead.org>
>> Cc: Andrew Morton<akpm@...ux-foundation.org>
>> Cc: Boris Ostrovsky<boris.ostrovsky@...cle.com>
>> Cc: Borislav Petkov<bp@...en8.de>
>> Cc: Daniel J Blueman<daniel@...ascale.com>
>> Cc: David Vrabel<david.vrabel@...rix.com>
>> Cc: Douglas Hatch<doug.hatch@...com>
>> Cc: H. Peter Anvin<hpa@...or.com>
>> Cc: Konrad Rzeszutek Wilk<konrad.wilk@...cle.com>
>> Cc: Linus Torvalds<torvalds@...ux-foundation.org>
>> Cc: Oleg Nesterov<oleg@...hat.com>
>> Cc: Paolo Bonzini<paolo.bonzini@...il.com>
>> Cc: Paul E. McKenney<paulmck@...ux.vnet.ibm.com>
>> Cc: Peter Zijlstra<peterz@...radead.org>
>> Cc: Raghavendra K T<raghavendra.kt@...ux.vnet.ibm.com>
>> Cc: Rik van Riel<riel@...hat.com>
>> Cc: Scott J Norton<scott.norton@...com>
>> Cc: Thomas Gleixner<tglx@...utronix.de>
>> Cc: virtualization@...ts.linux-foundation.org
>> Cc: xen-devel@...ts.xenproject.org
>> Link: http://lkml.kernel.org/r/1429901803-29771-10-git-send-email-Waiman.Long@hp.com
>> Signed-off-by: Ingo Molnar<mingo@...nel.org>
> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/