Linux-kernel mailing list archive 1999-34,: Re: Fw: Locks used in the FAT file system are non-atomic and in

# Re: Fw: Locks used in the FAT file system are non-atomic and in

Linus Torvalds (torvalds@transmeta.com)
Thu, 26 Aug 1999 12:54:02 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Alexandre Hautequest: "Re: strange problems with k2.2.11 / glibc 2.1 / xterm (xfree86 3.3.4)"
- Previous message: kuznet@ms2.inr.ac.ru: "Re: 2.3.15 ifconfig oops"

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/

- Next message: Alexandre Hautequest: "Re: strange problems with k2.2.11 / glibc 2.1 / xterm (xfree86 3.3.4)"
- Previous message: kuznet@ms2.inr.ac.ru: "Re: 2.3.15 ifconfig oops"