On Thu 15-12-16 15:07:14, Michal Hocko wrote:
> From: Michal Hocko <mhocko@xxxxxxxx>
>
> This reverts commit c45653c341f5c8a0ce19c8f0ad4678640849cb86 because
> sb_getblk_gfp is not really needed as
> sb_getblk
> __getblk_gfp
> __getblk_slow
> grow_buffers
> grow_dev_page
> gfp_mask = mapping_gfp_constraint(inode->i_mapping, ~__GFP_FS) | gfp
>
> so __GFP_FS is cleared unconditionally and therefore the above commit
> didn't have any real effect in fact.
>
> This patch should not introduce any functional change. The main point
> of this change is to reduce explicit GFP_NOFS usage inside ext4 code to
> make the review of the remaining usage easier.
>
> Signed-off-by: Michal Hocko <mhocko@xxxxxxxx>
Looks good to me. You can add:
Reviewed-by: Jan Kara <jack@xxxxxxx>
Honza
> ---
> fs/ext4/extents.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index b1f8416923ab..ef815eb72389 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -518,7 +518,7 @@ __read_extent_tree_block(const char *function, unsigned int line,
> struct buffer_head *bh;
> int err;
>
> - bh = sb_getblk_gfp(inode->i_sb, pblk, __GFP_MOVABLE | GFP_NOFS);
> + bh = sb_getblk(inode->i_sb, pblk);
> if (unlikely(!bh))
> return ERR_PTR(-ENOMEM);
>
> @@ -1096,7 +1096,7 @@ static int ext4_ext_split(handle_t *handle, struct inode *inode,
> err = -EFSCORRUPTED;
> goto cleanup;
> }
> - bh = sb_getblk_gfp(inode->i_sb, newblock, __GFP_MOVABLE | GFP_NOFS);
> + bh = sb_getblk(inode->i_sb, newblock);
> if (unlikely(!bh)) {
> err = -ENOMEM;
> goto cleanup;
> @@ -1290,7 +1290,7 @@ static int ext4_ext_grow_indepth(handle_t *handle, struct inode *inode,
> if (newblock == 0)
> return err;
>
> - bh = sb_getblk_gfp(inode->i_sb, newblock, __GFP_MOVABLE | GFP_NOFS);
> + bh = sb_getblk(inode->i_sb, newblock);
> if (unlikely(!bh))
> return -ENOMEM;
> lock_buffer(bh);
> --
> 2.10.2
>
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
