From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.linux-foundation.org (smtp2.linux-foundation.org [207.189.120.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.linux-foundation.org", Issuer "CA Cert Signing Authority" (verified OK)) by ozlabs.org (Postfix) with ESMTP id 21AE8DDF2E for ; Fri, 19 Oct 2007 08:53:39 +1000 (EST) Date: Thu, 18 Oct 2007 15:52:13 -0700 (PDT) From: Linus Torvalds To: Benjamin Herrenschmidt Subject: Re: [PATCH] synchronize_irq needs a barrier In-Reply-To: <1192745137.7367.40.camel@pasglop> Message-ID: References: <1192745137.7367.40.camel@pasglop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii Cc: linuxppc-dev@ozlabs.org, akpm@linux-foundation.org, Herbert Xu , linux-kernel@vger.kernel.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, 19 Oct 2007, Benjamin Herrenschmidt wrote: > > The barrier would guarantee that ioc->active (and in fact the write to > the chip too above) are globally visible No, it doesn't really guarantee that. The thing is, there is no such thing as "globally visible". There is a "ordering of visibility wrt CPU's", but it's not global, it's quite potentially per-CPU. So a barrier on one CPU doesn't guarantee anything at all without a barrier on the *other* CPU. That said, the interrupt handling itself contains various barriers on the CPU's that receive interrupts, thanks to the spinlocking. But I do agree with Herbert that adding a "smb_mb()" is certainly in no way "obviously correct", because it doesn't talk about what the other side does wrt barriers and that word in memory. Linus