Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932679AbbBIMva (ORCPT ); Mon, 9 Feb 2015 07:51:30 -0500 Received: from e23smtp02.au.ibm.com ([202.81.31.144]:56886 "EHLO e23smtp02.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932469AbbBIMv3 (ORCPT ); Mon, 9 Feb 2015 07:51:29 -0500 Message-ID: <54D8AD85.1070409@linux.vnet.ibm.com> Date: Mon, 09 Feb 2015 18:22:21 +0530 From: Raghavendra K T Organization: IBM User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Peter Zijlstra CC: Jeremy Fitzhardinge , tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, torvalds@linux-foundation.org, konrad.wilk@oracle.com, pbonzini@redhat.com, paulmck@linux.vnet.ibm.com, waiman.long@hp.com, davej@redhat.com, oleg@redhat.com, x86@kernel.org, paul.gortmaker@windriver.com, ak@linux.intel.com, jasowang@redhat.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, xen-devel@lists.xenproject.org, riel@redhat.com, borntraeger@de.ibm.com, akpm@linux-foundation.org, a.ryabinin@samsung.com, sasha.levin@oracle.com Subject: Re: [PATCH] x86 spinlock: Fix memory corruption on completing completions References: <1423234148-13886-1-git-send-email-raghavendra.kt@linux.vnet.ibm.com> <54D7D19B.1000103@goop.org> <54D87F1E.9060307@linux.vnet.ibm.com> <20150209120227.GT21418@twins.programming.kicks-ass.net> In-Reply-To: <20150209120227.GT21418@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15020912-0005-0000-0000-0000014F1D39 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 792 Lines: 20 On 02/09/2015 05:32 PM, Peter Zijlstra wrote: > On Mon, Feb 09, 2015 at 03:04:22PM +0530, Raghavendra K T wrote: >> So we have 3 choices, >> 1. xadd >> 2. continue with current approach. >> 3. a read before unlock and also after that. > > For the truly paranoid we have probe_kernel_address(), suppose the lock > was in module space and the module just got unloaded under us. > Thanks.. Good idea, How costly is it? atleast we could do probe_kernel_address() and check the value of slowpath flag if people as us to address invalid read problem. -- 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/