Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757378AbbBFQPw (ORCPT ); Fri, 6 Feb 2015 11:15:52 -0500 Received: from mail-ig0-f175.google.com ([209.85.213.175]:50611 "EHLO mail-ig0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755680AbbBFQPv (ORCPT ); Fri, 6 Feb 2015 11:15:51 -0500 MIME-Version: 1.0 In-Reply-To: <54D4DBA1.1030905@oracle.com> References: <1423234148-13886-1-git-send-email-raghavendra.kt@linux.vnet.ibm.com> <54D4DBA1.1030905@oracle.com> Date: Fri, 6 Feb 2015 08:15:50 -0800 X-Google-Sender-Auth: Ai_AAcSE9JJqaEhlFTYUT1jS6Vk Message-ID: Subject: Re: [PATCH] x86 spinlock: Fix memory corruption on completing completions From: Linus Torvalds To: Sasha Levin 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 , Andrew Morton , Andrey Ryabinin Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1296 Lines: 30 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. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/