Re: [2.6.29-rc5][BUG] swapon on vfat file gets stuck on inode lock

[OGAWA Hirofumi]

OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx>
> ---
>
>  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@xxxxxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/