More GFP_NOFS removals
David Sterba
maintainercover More GFP_NOFS removals
A few more conversions to less strict allocation flags, calls originating from an ioctl and with no chance of getting back with a lock already held. For 4.11.
The following changes since commit 2e94257a41fece589dc4bd737c70dc770e9040ef:
btrfs: Better csum error message for data csum mismatch (2017-02-10 18:04:51 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git dev/less-nofs
for you to fetch changes up to 8d310939a7d232fc71524fdf83f5a8fdbd5eb31c:
btrfs: use GFP_KERNEL in btrfs_add/del_qgroup_relation (2017-02-13 13:11:29 +0100)
----------------------------------------------------------------
David Sterba (4):
btrfs: use GFP_KERNEL in create_snapshot
btrfs: use GFP_KERNEL in btrfs_read_qgroup_config
btrfs: use GFP_KERNEL in btrfs_quota_enable
btrfs: use GFP_KERNEL in btrfs_add/del_qgroup_relation
fs/btrfs/ioctl.c | 4 ++-- fs/btrfs/qgroup.c | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-)
David Sterba
maintainerPATCH 1/4 btrfs: use GFP_KERNEL in create_snapshot
We don't need to use GFP_NOFS here as this is called from ioctls an the only lock held is the subvol_sem, which is of a high level and protects creation/renames/deletion and is never held in the writeout paths.
--- fs/btrfs/ioctl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/btrfs/ioctl.c +2 -2
@@ -670,12 +670,12 @@ static int create_snapshot(struct btrfs_root *root, struct inode *dir,if (!test_bit (BTRFS_ROOT_REF_COWS , &root->state))return -EINVAL ; - pending_snapshot =kzalloc (sizeof (*pending_snapshot),GFP_NOFS ); + pending_snapshot =kzalloc (sizeof (*pending_snapshot),GFP_KERNEL );if (!pending_snapshot)return -ENOMEM ; pending_snapshot->root_item =kzalloc (sizeof (struct btrfs_root_item ), -GFP_NOFS ); +GFP_KERNEL ); pending_snapshot->path =btrfs_alloc_path ();if (!pending_snapshot->root_item || !pending_snapshot->path) { ret = -ENOMEM ;
Signature · 1 line
2.10.1
David Sterba
maintainerPATCH 2/4 btrfs: use GFP_KERNEL in btrfs_read_qgroup_config
In reply to David SterbaThe qgroup config is read during mount, we do not have to use NOFS.
--- fs/btrfs/qgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/btrfs/qgroup.c +1 -1
@@ -319,7 +319,7 @@ int btrfs_read_qgroup_config(struct btrfs_fs_info *fs_info)if (!test_bit (BTRFS_FS_QUOTA_ENABLED , &fs_info->flags))return 0 ; - fs_info->qgroup_ulist =ulist_alloc (GFP_NOFS ); + fs_info->qgroup_ulist =ulist_alloc (GFP_KERNEL );if (!fs_info->qgroup_ulist) { ret = -ENOMEM ; goto out;
Signature · 1 line
2.10.1
David Sterba
maintainerPATCH 3/4 btrfs: use GFP_KERNEL in btrfs_quota_enable
In reply to David SterbaWe don't need to use GFP_NOFS here as this is called from ioctls an the only lock held is the subvol_sem, which is of a high level and protects creation/renames/deletion and is never held in the writeout paths.
--- fs/btrfs/qgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/btrfs/qgroup.c +1 -1
@@ -876,7 +876,7 @@ int btrfs_quota_enable(struct btrfs_trans_handle *trans, goto out; } - fs_info->qgroup_ulist =ulist_alloc (GFP_NOFS ); + fs_info->qgroup_ulist =ulist_alloc (GFP_KERNEL );if (!fs_info->qgroup_ulist) { ret = -ENOMEM ; goto out;
Signature · 1 line
2.10.1
David Sterba
maintainerPATCH 4/4 btrfs: use GFP_KERNEL in btrfs_add/del_qgroup_relation
In reply to David SterbaQgroup relations are added/deleted from ioctl, we hold the high level qgroup lock, no deadlocks or recursion from the allocation possible here.
--- fs/btrfs/qgroup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/btrfs/qgroup.c +2 -2
@@ -1174,7 +1174,7 @@ int btrfs_add_qgroup_relation(struct btrfs_trans_handle *trans,if (btrfs_qgroup_level (src) >=btrfs_qgroup_level (dst))return -EINVAL ; - tmp =ulist_alloc (GFP_NOFS ); + tmp =ulist_alloc (GFP_KERNEL );if (!tmp)return -ENOMEM ;
@@ -1234,7 +1234,7 @@ int __del_qgroup_relation(struct btrfs_trans_handle *trans,int ret =0 ;int err; - tmp =ulist_alloc (GFP_NOFS ); + tmp =ulist_alloc (GFP_KERNEL );if (!tmp)return -ENOMEM ;
Signature · 1 line
2.10.1