This is good to know. Now I know what's up. I think you are right -- we
were getting lucky because we weren't always hitting the window in the right
place. Conversion to semaphores is in process.
Jeff
----- Original Message -----
From: Linus Torvalds <torvalds@transmeta.com>
To: Jeff Merkey <jmerkey@timpanogas.com>
Cc: <linux-kernel@vger.rutgers.edu>
Sent: Thursday, August 26, 1999 1:54 PM
Subject: Re: Fw: Locks used in the FAT file system are non-atomic and
infact, don't work on SMP systems
>
>
> On Thu, 26 Aug 1999, Jeff Merkey wrote:
> >
> > You are also doing this in locks.h and the functions lock_super() and
> > unlock_super(). Am I missing something here? We used this same
> > method, and got corrupted data on SMP systems. It is possible for two
> > processes to blow up here by entering the function at the same time if
> > the lock variable is zero. It's hard to reproduce (we have to perform
> > cyclic copies with 8+ processes on a 4 processor system for over two
> > hours to reproduce, but there is a hole here if we use these locking
> > primitives the way you have defined them in locks.h.
>
> The locks.h code only works while holding the kernel lock.
>
> If you want a SMP-safe non-kernel-lock thing, you need to use the real
> semaphores (which is usually simpler anyway, and faster than the locks.h
> version: the only real reason to ever use the locks.h kind of lock is
> purely historical in old code).
>
> Easiest way to use a semaphore:
>
> DECLARE_MUTEX(random_semaphore);
> #define random_lock() down(&random_semaphore)
> #define random_unlock() up(&random_semaphore)
>
> and you're done.
>
> Linus
>
>
-
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/