On 05/12/2009 12:35 AM, Christoph Hellwig wrote: > Push down lock_super into ->write_super instances and remove it from the > caller. > > Following filesystem don't need ->s_lock in ->write_super and are skipped: > > * bfs, nilfs2 - no other uses of s_lock and have internal locks in > ->write_super > * ext2 - uses BKL in ext2_write_super and has internal calls without s_lock > * reiserfs - no other uses of s_lock as has reiserfs_write_lock (BKL) in > ->write_super > * xfs - no other uses of s_lock and uses internal lock (buffer lock on > superblock buffer) to serialize ->write_super. Also xfs_fs_write_super > is superflous and will go away in the next merge window > > > Signed-off-by: Christoph Hellwig <hch@xxxxxx> > Ack-by Boaz Harrosh <bharrosh@xxxxxxxxxxx> <snip> > =================================================================== > --- vfs-2.6.orig/fs/exofs/super.c 2009-05-11 23:26:24.971786995 +0200 > +++ vfs-2.6/fs/exofs/super.c 2009-05-11 23:28:12.929808342 +0200 > @@ -214,6 +214,7 @@ static void exofs_write_super(struct sup > return; > } > > + lock_super(sb); > lock_kernel(); > sbi = sb->s_fs_info; > fscb->s_nextid = cpu_to_le64(sbi->s_nextid); > @@ -246,6 +247,7 @@ out: > if (or) > osd_end_request(or); > unlock_kernel(); > + unlock_super(sb); > kfree(fscb); > } > Please I have a question about this? lock_super(): I do not see any other lock_super() in exofs, so all this might "lock" is race against itself, right? Should I make sure that concurrent exofs_write_super are protected some other way and remove this? lock_kernel(); What is that used for? What should I check so this can be removed? Sorry for the novice-ness ;-) Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
