Displaying 3 results from an estimated 3 matches for "sb_lock".
Did you mean:
fb_lock
2002 Dec 15
1
ext3 updates for 2.4.20
There are three patches at
http://www.zip.com.au/~akpm/linux/patches/2.4/2.4.20/
sync_fs.patch:
Fix the ext3 data=journal data-loss-on-unmount bug
sync_fs-fix.patch:
Fix sync_fs.patch to not deadlock the fs when running
`mount -o remount' against a heavily loaded filesystem.
ext3-use-after-free.patch
Fix a use-after-free bug which can cause memory corruption
if the filesystem runs
2002 Dec 06
2
[patch] fix the ext3 data=journal unmount bug
...@@ -454,6 +454,8 @@ void sync_supers(kdev_t dev)
if (sb) {
if (sb->s_dirt)
write_super(sb);
+ if (wait && sb->s_op && sb->s_op->sync_fs)
+ sb->s_op->sync_fs(sb);
drop_super(sb);
}
return;
@@ -467,6 +469,8 @@ restart:
spin_unlock(&sb_lock);
down_read(&sb->s_umount);
write_super(sb);
+ if (wait && sb->s_op && sb->s_op->sync_fs)
+ sb->s_op->sync_fs(sb);
drop_super(sb);
goto restart;
} else
--- linux-akpm/fs/ext3/super.c~sync_fs Thu Dec 5 21:33:56 2002
+++ linux-akpm-akpm/f...
2011 Jun 24
10
[PATCH 0/9] remove i_alloc_sem V2
i_alloc_sem has always been a bit of an odd "lock". It''s the only remaining
rw_semaphore that can be released by a different thread than the one that
locked it, and it''s use case in the core direct I/O code is more like a
counter given that the writers already have external serialization.
This series removes it in favour of a simpler counter scheme, thus getting
rid