Messages in this thread | | | From | OGAWA Hirofumi <> | Subject | Re: [2.6.29-rc5][BUG] swapon on vfat file gets stuck on inode lock | Date | Thu, 12 Mar 2009 03:13:34 +0900 |
| |
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:
> I'm sure that path touch the metadata without locking (so, reused entry > can not be for that inode anymore). However, I guess the result doesn't > become any fs corruption, so and other fs is ignoring the possibly wrong > result of bmap(). > > I'm thinking to use this patch instead of removing.
Ok. Simple stress test was done. BTW, since fat caches the metadata on that path, fat would be sensitive to race more than other fs.
Anyway, if you are ok, please apply. Otherwise, I'm going to prepare for this patch to next merge window.
Thanks.
> [PATCH] Fix _fat_bmap() locking > > On swapon() path, it has already i_mutex. So, this uses i_alloc_sem > instead of it. > > Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> > --- > > fs/fat/inode.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff -puN fs/fat/inode.c~fat_bmap-locking-fix fs/fat/inode.c > --- linux-2.6/fs/fat/inode.c~fat_bmap-locking-fix 2009-03-12 00:47:15.000000000 +0900 > +++ linux-2.6-hirofumi/fs/fat/inode.c 2009-03-12 00:47:42.000000000 +0900 > @@ -202,9 +202,9 @@ static sector_t _fat_bmap(struct address > sector_t blocknr; > > /* fat_get_cluster() assumes the requested blocknr isn't truncated. */ > - mutex_lock(&mapping->host->i_mutex); > + down_read(&mapping->host->i_alloc_sem); > blocknr = generic_block_bmap(mapping, block, fat_get_block); > - mutex_unlock(&mapping->host->i_mutex); > + up_read(&mapping->host->i_alloc_sem); > > return blocknr; > } > _
-- OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
| |