> The code is _very_ simple, and looks fine to me (and is noticeably
> faster). I was nervous about changing the atomic -> nonatomic thing, but
> if the scheduler spinlock wouldn't act as a synchronization point we'd
> have _so_ many problems that it wouldn't work at all (imagine the stack
> accesses getting old data on the new CPU etc ;) so I really cannot see
> how it could possibly not be correct.
2.1.112+smp_lock.h-fix+raid5.c-fixes is rock solid here after 2 hours of
heavy testing.
-- mingo
-
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.altern.org/andrebalsa/doc/lkml-faq.html