Re: Coldfire __lll_lock fails under heavy system stress

[Ed Slas <ed_slas at yahoo dot com>]

Joesph,?

Thanks for your time. I understand the kernel's atomic_cmpxchg_32() is most likely the issue, but note that most of the other platforms use a atomic lock in user space, then resort to the kernel to arbitrate contentions. The Coldfire port makes the?atomic_cmpxchg_32 kernel call first, when there is a user space atomic lock available (TAS instruction).


This said, I believe I have a 'better' way, i.e. follows the design of the other ports closer...and eliminates the dependency on the buggy atomic_cmpxchg_32.

Also note the coldfire TAS instruction was not added until the v4 version of this chip...so this is probably not a good fit for patching tip anyhow.?

Ed



----- Original Message -----
From: Joseph S. Myers <joseph@codesourcery.com>
To: Ed Slas <ed_slas@yahoo.com>
Cc: "libc-ports@sourceware.org" <libc-ports@sourceware.org>
Sent: Wednesday, October 31, 2012 3:43 PM
Subject: Re: Coldfire __lll_lock fails under heavy system stress

On Wed, 31 Oct 2012, Ed Slas wrote:

> I rarely delve this low into the code, so I cannot explain why this 
> implementation fails, but it is very suspicious that the kernel (2.6.38) 
> interrupt handler repositions the PC if it sees the PC at interrupt was 
> in atomic_cmpxchg_32().

Given what you have described, there is no evidence for a bug in glibc 
rather than the kernel (and so no evidence that the problem you see should 
be fixed in glibc rather than the kernel).

-- 
Joseph S. Myers
joseph@codesourcery.com