From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: next-20090310: ext4 hangs Date: Thu, 26 Mar 2009 01:00:36 +0100 Message-ID: <20090326000035.GB11024@duck.suse.cz> References: <20090325151122.GA14881@atrey.karlin.mff.cuni.cz> <20090325151516.GB14881@atrey.karlin.mff.cuni.cz> <20090325152234.GN23439@duck.suse.cz> <20090325161556.GP23439@duck.suse.cz> <20090325194316.GQ23439@duck.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-ext4-owner@vger.kernel.org To: Alexander Beregalov Cc: Theodore Tso , "linux-next@vger.kernel.org" , linux-ext4@vger.kernel.org, LKML , sparclinux@vger.kernel.org List-Id: linux-next.vger.kernel.org Hi, thanks for the updated disassembly. > 55bab0: 82 10 60 01 or %g1, 1, %g1 > spin_unlock(&journal->j_list_lock); > 55bab4: 40 06 4b 20 call 6ee734 <_spin_unlock> > 55bab8: c2 24 e0 28 st %g1, [ %l3 + 0x28 ] OK, so it really seems that: jinode->i_flags |= JI_COMMIT_RUNNING; spin_unlock(&journal->j_list_lock); has been compiled to ld [ %l3 + 0x28 ], %g1 or %g1, 1, %g1 call 6ee734 <_spin_unlock> st %g1, [ %l3 + 0x28 ] Which seems like a bug in the compiler or in the way implement compiler barriers in spin_unlock() on UP sparc. Or is there some sparc magic by which this is correct code? Any clever sparc guy? Honza -- Jan Kara SUSE Labs, CR