Commit graph

5 commits

Author SHA1 Message Date
OGAWA Hirofumi
98283bb49c fat: Fix the race of read/write the FAT12 entry
FAT12 entry is 12bits, so it needs 2 phase to update the value.  And
writer and reader access it without any lock, so reader can get the
half updated value.

This fixes the long standing race condition by adding a global
spinlock to only FAT12 for avoiding any impact against FAT16/32.

Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-16 10:31:01 -07:00
Arjan van de Ven
6b9438e132 [PATCH] fat_lock is used as a mutex, convert it to using the new mutex primitive
The fat code uses the fat_lock always in a mutex way (taking and releasing
the lock in the same function), the patch below converts it into the new
mutex primitive.  Please consider this patch for the code.

Signed-off-by: Arjan van de Ven <arjan@infradead.org>
Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-23 07:38:15 -08:00
OGAWA Hirofumi
7c709d00d6 [PATCH] fat: s/EXPORT_SYMBOL/EXPORT_SYMBOL_GPL/
All EXPORT_SYMBOL of fatfs is only for vfat/msdos. _GPL would be proper.

Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08 20:13:46 -08:00
OGAWA Hirofumi
a6bf6b211c [PATCH] fat: move fat_clusters_flush() to write_super()
It is overkill to update the FS_INFO whenever modifying
prev_free/free_clusters, because those are just a hint.

So, this patch uses ->write_super() for updating FS_INFO instead.

Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08 20:13:46 -08:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00