Re: MIPS_ATOMIC_SET again (Re: newest kernel

[Joe deBlaquiere <jadb@redhat.com>]

I would vote for option #4 - make sure the ll/sc emulation stuff works 
and use ll/sc in glibc instead of sysmips. Beyond the pthreads mutex 
stuff in glibc I have yet to come across usage of sysmips. Of course you 
still need sys_sysmips to function correctly (in case somebody did a 
silly thing like call sysmips directly just for the fun of it), so I 
like like Florian's solution. Adding a parameter is a silly thing to do, 
and we don't need to be adding functionality to sys_sysmips through 
NEW_MO_BETTER_AS_SEEN_ON_TV_ATOMIC_SET or what have you...

Joe

Jun Sun wrote:

> Florian Lohoff wrote:
> 
>> On Mon, May 21, 2001 at 04:23:52PM -0700, Jun Sun wrote:
>> 
>>> The patch seems to be just a fast implementation of sysmips().  Why would it
>>> solve an otherwise illegal instruction problem?
>>> 
>>> George, what was exactly the error and the faulty instruction?
>> 
>> Wrong - Its not only a "fast" path sysmips. It solves the illegal instruction
>> case as it carefully doesnt touch registers it should not touch.
>> 
>> The sysmips illegal instruction stuff came from the early exit
>> needed to skip the -EXXXX case in the scall32.S which did not
>> restore the modified registers. This needed fixing and there was
>> no clean way of doing this in C thus i wrote an asm sysmips/MIPS_ATOMIC_SET
>> and called it "fast_sysmips" which itself would go into the old
>> sysmips function when not MIPS_ATOMIC_SET.
>> 
> 
> 
> I see.
> 
> I took a look of MIPS ABI in system V and found that the spec only specifies
> this extended call in C prototype:
> 
> int _test_and_set(int *p, int v);
> 
> It seems perfectly legal for us to add one more argument to store the return
> value while still have the function returns error.  Of course, doing that will
> break binary compatibility.
> 
> Otherwise, I think Flo's patch is the best fix to satisfy the spec and binary
> compatibility although it is a little clunky.
> 
> A third possibility is the have a MIPS_NEW_ATOMIC_SET that take three
> arguments.  If that approach is taken, I would take out the inline assembly
> that jumps to o32_ret_from_sys_call and documents MIPS_ATOMIC_SET as
> deprecated and valnerable.
> 
> My preference, in the decreasing order, is 3), 2) and 1).
> 
> Ralf, what do you think?  We cannot let the bug sit around in the CVS tree for
> long.  Have to have some fix.
> 
> Jun


-- 
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax   : (256)-837-3839