Re: [patch 3/8] mutex subsystem, add atomic_*_call_if_*() to i386

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Linus Torvalds <[email protected]> wrote:

> > Umm. This asm is broken. It doesn't mark %eax as changed, so this is only 
> > reliable if the function you call is
> > 
> >  - a "fastcall" one
> >  - always returns as its return value the pointer to the atomic count
> > 
> > which is not true (you verify that it's a fastcall, but it's of type 
> > "void").
> 
> Actually (and re-reading the email I sent that wasn't obvious at all), 
> my _preferred_ fix is to literally force the use of the above kind of 
> function: not save/restore %eax at all, but just say that any function 
> that is called by the magic "atomic_*_call_if()" needs to always 
> return the argument it gets as its return value too.
> 
> That allows the caller to not even have to care. And the callee 
> obviously already _has_ that value, so it might as well return it (and 
> in the best case it's not going to add any cost at all, either to the 
> caller or the callee).
> 
> So you might opt to keep the asm the same, just change the calling 
> conventions.

ok, i've added this fix, thanks. Right now we dont do anything after 
those functions (that's probably how the bug never showed up), but at 
least one interim stage i tried to use the call_if functions at other 
places too, so the potential is there.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux