mm: Fix SHM_HUGETLB to work with users in hugetlb_shm_group
Subsystems (3)
PATCH 1/2 mm: Fix SHM_HUGETLB to work with users in hugetlb_shm_group
This is a two patch series to fix a long standing inconsistency with the mechanism to allow non root users allocate hugetlb shm. The patch changelog is self explanatory. Here's a link to the previous discussion as well:
http://lkml.org/lkml/2009/2/10/89
---
Fix hugetlb subsystem so that non root users belonging to hugetlb_shm_group can actually allocate hugetlb backed shm.
Currently non root users cannot even map one large page using SHM_HUGETLB when they belong to the gid in /proc/sys/vm/hugetlb_shm_group. This is because allocation size is verified against RLIMIT_MEMLOCK resource limit even if the user belongs to hugetlb_shm_group.
This patch
1. Fixes hugetlb subsystem so that users with CAP_IPC_LOCK and users belonging to hugetlb_shm_group don't need to be restricted with RLIMIT_MEMLOCK resource limits
2. This patch also disables mlock based rlimit checking (which will be reinstated and marked deprecated in a subsequent patch).
fs/hugetlbfs/inode.c +1 -7
@@ -942,9 +942,7 @@ static struct vfsmount *hugetlbfs_vfsmoustatic int can_do_hugetlb_shm (void ) { -return likely (capable (CAP_IPC_LOCK ) || -in_group_p (sysctl_hugetlb_shm_group) || -can_do_mlock ()); +return (capable (CAP_IPC_LOCK ) ||in_group_p (sysctl_hugetlb_shm_group)); }struct file *hugetlb_file_setup (const char *name,size_t size)
@@ -962,9 +960,6 @@ struct file *hugetlb_file_setup(const chif (!can_do_hugetlb_shm ())return ERR_PTR (-EPERM ); -if (!user_shm_lock (size, user)) -return ERR_PTR (-ENOMEM ); - root = hugetlbfs_vfsmount->mnt_root; quick_string.name = name; quick_string.len =strlen (quick_string.name);
@@ -1002,7 +997,6 @@ out_inode: out_dentry:dput (dentry); out_shm_unlock: -user_shm_unlock (size, user);return ERR_PTR (error); }
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 2/2 mm: Reintroduce and deprecate rlimit based access for SHM_HUGETLB
Allow non root users with sufficient mlock rlimits to be able to allocate hugetlb backed shm for now. Deprecate this though. This is being deprecated because the mlock based rlimit checks for SHM_HUGETLB is not consistent with mmap based huge page allocations.
fs/hugetlbfs/inode.c +11 -2
@@ -948,6 +948,7 @@ static int can_do_hugetlb_shm(void)struct file *hugetlb_file_setup (const char *name,size_t size) {int error = -ENOMEM ; +int unlock_shm =0 ;struct file *file;struct inode *inode;struct dentry *dentry, *root;
@@ -957,8 +958,14 @@ struct file *hugetlb_file_setup(const chif (!hugetlbfs_vfsmount)return ERR_PTR (-ENOENT ); -if (!can_do_hugetlb_shm ()) -return ERR_PTR (-EPERM ); +if (!can_do_hugetlb_shm ()) { +if (user_shm_lock (size, user)) { + unlock_shm =1 ; +WARN_ONCE (1 , +"Using mlock ulimits for SHM_HUGETLB deprecated\n" ); + }else +return ERR_PTR (-EPERM ); + } root = hugetlbfs_vfsmount->mnt_root; quick_string.name = name;
@@ -997,6 +1004,8 @@ out_inode: out_dentry:dput (dentry); out_shm_unlock: +if (unlock_shm) +user_shm_unlock (size, user);return ERR_PTR (error); }
Documentation/feature-removal-schedule.txt +11 -0
@@ -335,3 +335,14 @@ Why: In 2.6.18 the Secmark concept was i Secmark, it is time to deprecate the older mechanism and start the process of removing the old code. Who: Paul Moore <[email protected]> +--------------------------- + +What: Ability for non root users to shm_get hugetlb pages based on mlock + resource limits +When: 2.6.31 +Why: Non root users need to be part of /proc/sys/vm/hugetlb_shm_group or + have CAP_IPC_LOCK to be able to allocate shm segments backed by + huge pages. The mlock based rlimit check to allow shm hugetlb is + inconsistent with mmap based allocations. Hence it is being + deprecated. +Who: Ravikiran Thirumalai <[email protected]>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [patch 2/2] mm: Reintroduce and deprecate rlimit based access for SHM_HUGETLB
Quoted 26 lines · Ravikiran G Thirumalai
Allow non root users with sufficient mlock rlimits to be able to allocate hugetlb backed shm for now. Deprecate this though. This is being deprecated because the mlock based rlimit checks for
SHM_HUGETLBis not consistent with mmap based huge page allocations.Signed-off-by Ravikiran Thirumalai <[email protected]>Cc Mel Gorman <[email protected]>Cc Wli <[email protected]>Index:
linux-2.6-tip/fs/hugetlbfs/inode.c
===================================================================fs/hugetlbfs/inode.c +1
-1@@ -948,6 +948,7 @@ static int can_do_hugetlb_shm(void)struct file *hugetlb_file_setup (const char *name,size_t size) {int error = -ENOMEM ; +int unlock_shm =0 ;struct file *file;struct inode *inode;struct dentry *dentry, *root;@@ -957,8 +958,14 @@ struct file *hugetlb_file_setup(const chif (!hugetlbfs_vfsmount)return ERR_PTR (-ENOENT ); -if (!can_do_hugetlb_shm ())
fs/hugetlbfs/inode.c struct file *hugetlb_file_setup(const ch · line 969
Quoted 10 lines
fs/hugetlbfs/inode.c +8
-1-return ERR_PTR (-EPERM ); +if (!can_do_hugetlb_shm ()) { +if (user_shm_lock (size, user)) { + unlock_shm =1 ; +WARN_ONCE (1 , +"Using mlock ulimits for SHM_HUGETLB deprecated\n" ); + }else +return ERR_PTR (-EPERM ); + }
Seems to do what is promised by the patch and basic tests worked out for me. I think the behaviour has changed slightly in that we are getting EPERM now where we might have seen ENOMEM before but that should be ok.
Quoted 21 lines
fs/hugetlbfs/inode.c +2
-0root = hugetlbfs_vfsmount->mnt_root; quick_string.name = name;@@ -997,6 +1004,8 @@ out_inode: out_dentry:dput (dentry); out_shm_unlock: +if (unlock_shm) +user_shm_unlock (size, user);return ERR_PTR (error); }Index:
linux-2.6-tip/Documentation/feature-removal-schedule.txt
===================================================================Documentation/feature-removal-schedule.txt +1
-0@@ -335,3 +335,14 @@ Why: In 2.6.18 the Secmark concept was i Secmark, it is time to deprecate the older mechanism and start the process of removing the old code. Who: Paul Moore <[email protected]> +---------------------------
Documentation/feature-removal-schedule.txt Why: In 2.6.18 the Secmark concept was i · line 348
Quoted 10 lines
Documentation/feature-removal-schedule.txt +10
-0+ +What: Ability for non root users to shm_get hugetlb pages based on mlock + resource limits +When: 2.6.31 +Why: Non root users need to be part of /proc/sys/vm/hugetlb_shm_group or + have CAP_IPC_LOCK to be able to allocate shm segments backed by + huge pages. The mlock based rlimit check to allow shm hugetlb is + inconsistent with mmap based allocations. Hence it is being + deprecated. +Who: Ravikiran Thirumalai <[email protected]>
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 31 lines · Ravikiran G Thirumalai
This is a two patch series to fix a long standing inconsistency with the mechanism to allow non root users allocate hugetlb shm. The patch changelog is self explanatory. Here's a link to the previous discussion as well:
http://lkml.org/lkml/2009/2/10/89---
Fix hugetlb subsystem so that non root users belonging tohugetlb_shm_groupcan actually allocate hugetlb backed shm.Currently non root users cannot even map one large page using
SHM_HUGETLBwhen they belong to the gid in/proc/sys/vm/hugetlb_shm_group. This is because allocation size is verified againstRLIMIT_MEMLOCKresource limit even if the user belongs tohugetlb_shm_group.This patch
1. Fixes hugetlb subsystem so that users withCAP_IPC_LOCKand users belonging tohugetlb_shm_groupdon't need to be restricted withRLIMIT_MEMLOCKresource limits
2. This patch also disables mlock based rlimit checking (which will be reinstated and marked deprecated in a subsequent patch).Signed-off-by Ravikiran Thirumalai <[email protected]>Cc Mel Gorman <[email protected]>Cc Wli <[email protected]>Index:
linux-2.6-tip/fs/hugetlbfs/inode.c
===================================================================
fs/hugetlbfs/inode.c static struct vfsmount *hugetlbfs_vfsmou · line 947
Quoted 9 lines
fs/hugetlbfs/inode.c +1
-3@@ -942,9 +942,7 @@ static struct vfsmount *hugetlbfs_vfsmoustatic int can_do_hugetlb_shm (void ) { -return likely (capable (CAP_IPC_LOCK ) || -in_group_p (sysctl_hugetlb_shm_group) || -can_do_mlock ()); +return (capable (CAP_IPC_LOCK ) ||in_group_p (sysctl_hugetlb_shm_group)); }
checkpatch complains about the () around the check being unnecessary. Not a big issue though.
Quoted 12 lines
fs/hugetlbfs/inode.c +0
-3struct file *hugetlb_file_setup (const char *name,size_t size)@@ -962,9 +960,6 @@ struct file *hugetlb_file_setup(const chif (!can_do_hugetlb_shm ())return ERR_PTR (-EPERM ); -if (!user_shm_lock (size, user)) -return ERR_PTR (-ENOMEM ); - root = hugetlbfs_vfsmount->mnt_root; quick_string.name = name; quick_string.len =strlen (quick_string.name);
fs/hugetlbfs/inode.c out_inode: · line 1002
Quoted 7 lines
fs/hugetlbfs/inode.c +0
-1@@ -1002,7 +997,6 @@ out_inode: out_dentry:dput (dentry); out_shm_unlock: -user_shm_unlock (size, user);return ERR_PTR (error); }
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Ravikiran G Thirumalai
Reviewed-by Mel GormanQuoted 11 lines · Mel Gorman
Quoted 6 lines · Ravikiran G Thirumalai
This is a two patch series to fix a long standing inconsistency with the mechanism to allow non root users allocate hugetlb shm. The patch changelog is self explanatory. Here's a link to the previous discussion as well:
http://lkml.org/lkml/2009/2/10/89checkpatch complains about the () around the check being unnecessary. Not a big issue though.
Hmm! I could have sworn I ran it through checkpatch.pl (usually I do) but apparently this time I didn't. Here's the corrected patch.
Thanks,
Kiran
---
Fix hugetlb subsystem so that non root users belonging to hugetlb_shm_group can actually allocate hugetlb backed shm.
Currently non root users cannot even map one large page using SHM_HUGETLB when they belong to the gid in /proc/sys/vm/hugetlb_shm_group. This is because allocation size is verified against RLIMIT_MEMLOCK resource limit even if the user belongs to hugetlb_shm_group.
This patch
1. Fixes hugetlb subsystem so that users with CAP_IPC_LOCK and users belonging to hugetlb_shm_group don't need to be restricted with RLIMIT_MEMLOCK resource limits
2. This patch also disables mlock based rlimit checking (which will be reinstated and marked deprecated in a subsequent patch).
fs/hugetlbfs/inode.c +1 -7
@@ -943,9 +943,7 @@ static struct vfsmount *hugetlbfs_vfsmoustatic int can_do_hugetlb_shm (void ) { -return likely (capable (CAP_IPC_LOCK ) || -in_group_p (sysctl_hugetlb_shm_group) || -can_do_mlock ()); +return capable (CAP_IPC_LOCK ) ||in_group_p (sysctl_hugetlb_shm_group); }struct file *hugetlb_file_setup (const char *name,size_t size,int acctflag)
@@ -963,9 +961,6 @@ struct file *hugetlb_file_setup(const chif (!can_do_hugetlb_shm ())return ERR_PTR (-EPERM ); -if (!user_shm_lock (size, user)) -return ERR_PTR (-ENOMEM ); - root = hugetlbfs_vfsmount->mnt_root; quick_string.name = name; quick_string.len =strlen (quick_string.name);
@@ -1004,7 +999,6 @@ out_inode: out_dentry:dput (dentry); out_shm_unlock: -user_shm_unlock (size, user);return ERR_PTR (error); }
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>