From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrey Ryabinin Subject: Re: [PATCH] x86 spinlock: Fix memory corruption on completing completions Date: Fri, 06 Feb 2015 20:03:14 +0300 Message-ID: <54D4F3D2.3010807@samsung.com> References: <1423234148-13886-1-git-send-email-raghavendra.kt@linux.vnet.ibm.com> <54D4DBA1.1030905@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Raghavendra K T , Thomas Gleixner , Ingo Molnar , Peter Anvin , Peter Zijlstra , Konrad Rzeszutek Wilk , Paolo Bonzini , Paul McKenney , Waiman Long , Dave Jones , Oleg Nesterov , the arch/x86 maintainers , Jeremy Fitzhardinge , Paul Gortmaker , Andi Kleen , Jason Wang , Linux Kernel Mailing List , KVM list , virtualization , xen-devel@lists.xenproject.org, Rik van Riel , Christian Borntraeger , A To: Linus Torvalds , Sasha Levin Return-path: In-reply-to: Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 02/06/2015 07:15 PM, Linus Torvalds wrote: > On Fri, Feb 6, 2015 at 7:20 AM, Sasha Levin wrote: >> >> Can we modify it slightly to avoid potentially accessing invalid memory: > > So I think there's a race with that. > > And I'll warn you: the kernel does do speculative reads of memory that > might be invalid, not just in places like this. See the comment in > get_user_huge_page() for example, where we knowingly do speculative > reads, but hide it if DEBUG_PAGEALLOC is set. > > More commonly, CONFIG_DCACHE_WORD_ACCESS is very much about doing > speculative reads. Now, that access is hidden inside an asm, so KASan > won't see it, but there might well be others. > > You probably don't see them very much just because they are so rarely > a problem, and most of the time it's not to other processes stack but > to allocated structures where freeing takes long enough to basically > hide any small race.. > > In other words: I suspect it would be good to instead just teach KASan > about "this is a speculative read" and just suppress the warning for > those instead. > We can suppress warnings by wrapping such speculative reads with kasan_disable_current()/kasan_enable_current() calls.