Thorsten,great work on pinning this bug down - and full kudos to Andreas for the fix.
Andreas Schwab dixit:Obviously the syscall has never been tested on m68k. <http://permalink.gmane.org/gmane.linux.ports.m68k/4149>
Greg, can we get the above fix by Andreas into the stable series please?Thorsten tried to send mail to stable@kernel.org but it got bounced - please advise if you're not a suitable point of contact for this kind of request.
We can always get it submitted through Geert's tree if that's easier.
Since it does not appear to cause any real harm (presumaby nfeth still works after the message?), I'd leave it.Thanks, that fixes the problem. I’ve written an answer adding my Tested-by and Cc'd stable@ as waldi suggested; if someone here thinks that c663600584a596b5e66258cc10716fb781a5c2c9 also should be added to stable, please do the same, I cannot judge that.
It seems to say this really is not needed unless building glibc for use on both CF and classic m68k:When duckduckgoïng for the problem and atomic stuff in general I found <Pine.LNX.4.64.0711301901100.20112@digraph.polyomino.org.uk> and wonder where __kernel_atomic_cmpxchg_32 is; should probably be in libc? no vDSO, but it could still switch between doing the trap or using CAS… and gcc should then use that?
And I seem to recall we were not going to do anything like this, for performance reasons on both architectures.(On m68k - where this kernel helper would only be used if glibc is built for the intersection of ColdFire and m68k - this could be implemented with a single cas instruction and a return.)
Cheers, Michael