From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [rfc] data race in page table setup/walking? Date: Wed, 30 Apr 2008 07:37:39 +1000 Message-ID: <1209505059.18023.193.camel@pasglop> References: <20080429050054.GC21795@wotan.suse.de> Reply-To: benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-arch-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: To: Hugh Dickins Cc: Nick Piggin , Linus Torvalds , linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Memory Management List On Tue, 2008-04-29 at 13:36 +0100, Hugh Dickins wrote: > > Ugh. It's just so irritating to introduce these blockages against > such a remote possibility (but there again, that's what so much of > kernel code has to be about). Is there any other way of handling it? Not that much overhead... I think smp_read_barrier_depends() is a nop on most archs no ? The data dependency between all the pointers takes care of ordering in many cases. So it boils down to smp_wmb's when setting which is not that expensive. Cheers, Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org ([63.228.1.57]:40073 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752246AbYD2Vic (ORCPT ); Tue, 29 Apr 2008 17:38:32 -0400 Subject: Re: [rfc] data race in page table setup/walking? From: Benjamin Herrenschmidt Reply-To: benh@kernel.crashing.org In-Reply-To: References: <20080429050054.GC21795@wotan.suse.de> Content-Type: text/plain Date: Wed, 30 Apr 2008 07:37:39 +1000 Message-ID: <1209505059.18023.193.camel@pasglop> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Hugh Dickins Cc: Nick Piggin , Linus Torvalds , linux-arch@vger.kernel.org, Linux Memory Management List Message-ID: <20080429213739.kRUOkpL3C3ASbJr2zcujJGmwsMq3x4PxckQcSsIx0_0@z> On Tue, 2008-04-29 at 13:36 +0100, Hugh Dickins wrote: > > Ugh. It's just so irritating to introduce these blockages against > such a remote possibility (but there again, that's what so much of > kernel code has to be about). Is there any other way of handling it? Not that much overhead... I think smp_read_barrier_depends() is a nop on most archs no ? The data dependency between all the pointers takes care of ordering in many cases. So it boils down to smp_wmb's when setting which is not that expensive. Cheers, Ben.