On Mon, 7 April 2008 10:28:41 +0200, Jens Axboe wrote: > > > > fs/block_dev.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > --- linux-2.6.24logfs/fs/block_dev.c~blockdev_nofs 2008-04-07 10:19:08.627413077 +0200 > > +++ linux-2.6.24logfs/fs/block_dev.c 2008-04-07 10:20:56.927117162 +0200 > > @@ -586,7 +586,7 @@ struct block_device *bdget(dev_t dev) > > inode->i_rdev = dev; > > inode->i_bdev = bdev; > > inode->i_data.a_ops = &def_blk_aops; > > - mapping_set_gfp_mask(&inode->i_data, GFP_USER); > > + mapping_set_gfp_mask(&inode->i_data, GFP_USER & ~__GFP_FS); > > inode->i_data.backing_dev_info = &default_backing_dev_info; > > spin_lock(&bdev_lock); > > list_add(&bdev->bd_list, &all_bdevs); > > It's not the right fix, generally GFP_FS is fine here. So do that in > logfs when you cannot traverse back into the fs, eg > > mapping_gfp_mask(mapping) & ~__GFP_FS; > > locally. struct address_space *mapping; /* Prevent bdev from calling back into fs */ mapping = &logfs_super(sb)->s_bdev->bd_inode->i_data; mapping_set_gfp_mask(mapping, mapping_gfp_mask(mapping) & ~__GFP_FS); bd_inode has an interesting comment: struct inode * bd_inode; /* will die */ Should I be worried about that? It seems to predate git history, so I'm not too concerned about immediate changes. Jörn -- Unless something dramatically changes, by 2015 we'll be largely wondering what all the fuss surrounding Linux was really about. -- Rob Enderle -- 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
