lkml.org 
[lkml]   [1999]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.2.2 kernel is out
On Tue, 23 Feb 1999, Geert Uytterhoeven wrote:

>On Tue, 23 Feb 1999, Tom Rini wrote:
>> On Mon, 22 Feb 1999, Andrew Stone wrote:
>>
>> > Just reported on Slashdot - the 2.2.2 kernel is out.
>>
>> ...and needs a ppc __down_trylock. :)
>
>And a m68k __down_trylock, and a SPARC __down_trylock (already in vger), and an
>ARM __down_trylock, and a MIPS __down_trylock, and an AXP __down_trylock :-(
>
>Sorry, but I just can't believe such things happen on a `stable' branch....

You would have to rewrite the semaphores anyway because we killed
recursive semaphores. Since you have to rewrite all semaphores you can
also handle to add two lines for __down_trylock to the code I think. I
really don't think __down_trylock it's the issue. If you understand
semaphores you'll see that down_trylock() implementation is obvious and
the down_trylock problem can be trivally reduced to down_interrutible().

The _real_ issue is the killing of the recursive semaphores that everybody
non-x86 will have to handle. And we _couldn't_ cut and paste the 2.1.x
no-x86 semaphores since is been discovered a looong standing but real and
potential race in down_interruptible(). It was a really small window but
possible.

I don't think it would be a good idea (better than break all no-x86 arch)
to take recursive semaphores of 2.2.1 (that was causing some crashes and
that people started to add .owner = 0) with also the discovered
down_interruptible() race unfixed in the whole 2.2.x branch. Do you see
the point for the change now Geert? I understand that without knowing
these issues such change could looks as a bit crazy.

The only _unluky_ thing :( is that my first fix (the one in 2.2.2) has
still a little window for a similar race again in down_interruptible() and
down_trylock(), and I should have fixed it completly only in the last
days. You can find my patch against 2.2.2-pre5 (or 2.2.2) on the list. The
new patch is quite simple and the race won't have the time impact somebody
in the meantime but it's still not perfect (even if closer). Excuse me.

So I suggest all no-x86 arch developers to apply my latest semaphore patch
before starting fixing semaphores.

Also I don't know if it worth to move the semaphore-helper.h to
include/linux. Doing that (using the spinlock everywhere) and so following
the x86 semaphore implementation, it would be semi-trivial for no-x86
maintainers to fix their trees without having to think (too much ;) about
the races.

Comments?

Andrea Arcangeli


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.036 / U:1.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site