Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754519AbYAQG7d (ORCPT ); Thu, 17 Jan 2008 01:59:33 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751891AbYAQG7Y (ORCPT ); Thu, 17 Jan 2008 01:59:24 -0500 Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]:50882 "EHLO fgwmail5.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751821AbYAQG7X (ORCPT ); Thu, 17 Jan 2008 01:59:23 -0500 Date: Thu, 17 Jan 2008 15:59:24 +0900 From: KOSAKI Motohiro To: Roland Dreier Subject: Re: Bitops source problem Cc: kosaki.motohiro@jp.fujitsu.com, "Pravin Nanaware" , "John Hubbard" , "LKML" In-Reply-To: References: <1145971D427D7F43B0DBDAE22221C4B502CCE22D@nipns00a210.FPS.NIHILENT.COM> Message-Id: <20080117155723.11DC.KOSAKI.MOTOHIRO@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.42 [ja] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 947 Lines: 29 Hi > If that is indeed the source of your change_bit function then there is > a problem. However in my kernel tree there is a LOCK_PREFIX in the > definition of the atomic version. I don't have your exact source tree > handy, but on a local RHEL4 system, the LOCK_PREFIX is still there: > > static inline void change_bit(int nr, volatile unsigned long * addr) > { > __asm__ __volatile__( LOCK_PREFIX > "btcl %1,%0" > :"=m" (ADDR) > :"Ir" (nr)); > } 2.6.24-rc6-mm1 have LOCK_PREFIX too :) static inline void change_bit(int nr, volatile void *addr) { asm volatile(LOCK_PREFIX "btc %1,%0" : ADDR : "Ir" (nr)); } -- 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/