From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Subject: Re: [RFC patch 08/18] cnt32_to_63 should use smp_rmb() Date: Fri, 07 Nov 2008 10:55:12 +0000 Message-ID: <25257.1226055312@redhat.com> References: <20081107053349.861709786@polymtl.ca> <20081107052336.652868737@polymtl.ca> Return-path: Received: from mx2.redhat.com ([66.187.237.31]:45822 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751796AbYKGK4R (ORCPT ); Fri, 7 Nov 2008 05:56:17 -0500 In-Reply-To: <20081107053349.861709786@polymtl.ca> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Mathieu Desnoyers , "Paul E. McKenney" Cc: dhowells@redhat.com, Linus Torvalds , akpm@linux-foundation.org, Ingo Molnar , Peter Zijlstra , linux-kernel@vger.kernel.org, Nicolas Pitre , Ralf Baechle , benh@kernel.crashing.org, paulus@samba.org, David Miller , Ingo Molnar , Thomas Gleixner , Steven Rostedt , linux-arch@vger.kernel.org Mathieu Desnoyers wrote: > Assume the time source is a global clock which insures that time will never > *ever* go backward. Use a smp_rmb() to make sure the cnt_lo value is read before > __m_cnt_hi. If you have an smp_rmb(), then don't you need an smp_wmb()/smp_mb() to match it to make it work? And is your assumption valid that smp_rmb() will affect memory vs the I/O access to read the clock? There's no requirement that cnt_lo will have been read from an MMIO location at all. David