hugetlb: remove user_shm_lock() check from hugetlb_file_setup()

PATCH NAK Américo Wang 2 participants 4 messages Jun 18, 2011 – Jun 23, 2011

Subsystems (2)

Documentation HugeTLB

lore

Share & tools

lore

Américo Wang

author

2011-06-18 07:13 UTC #0 lore raw

PATCH 1/1 hugetlb: remove user_shm_lock() check from hugetlb_file_setup()

This is a revert of

commit 2584e517320bd48dc8d20e38a2621a2dbe58fade

Author: Ravikiran G Thirumalai <[email protected]>
Date:   Tue Mar 31 15:21:26 2009 -0700

mm: reintroduce and deprecate rlimit based access for SHM_HUGETLB

because it is deprecated and scheduled to be removed.

Cc Mel Gorman <[email protected]>

Cc Ravikiran Thirumalai <[email protected]>

Signed-off-by WANG Cong <[email protected]>

---

Documentation/feature-removal-schedule.txt +0 ~~-12~~

index 72e2384..d627fd3 100644
@@ -298,18 +298,6 @@ Who:	Michael Buesch <[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]>
-
----------------------------
-
 What:	CONFIG_THERMAL_HWMON
 When:	January 2009
 Why:	This option was introduced just to allow older lm-sensors userspace

fs/hugetlbfs/inode.c +4 ~~-15~~

index 7aafeb8..e2627a3 100644
@@ -936,15 +936,8 @@ struct file *hugetlb_file_setup(const char *name, size_t size,
 	if (!hugetlbfs_vfsmount)
 		return ERR_PTR(-ENOENT);
 
-	if (creat_flags == HUGETLB_SHMFS_INODE && !can_do_hugetlb_shm()) {
-		*user = current_user();
-		if (user_shm_lock(size, *user)) {
-			printk_once(KERN_WARNING "Using mlock ulimits for SHM_HUGETLB is deprecated\n");
-		} else {
-			*user = NULL;
-			return ERR_PTR(-EPERM);
-		}
-	}
+	if (creat_flags == HUGETLB_SHMFS_INODE && !can_do_hugetlb_shm())
+		return ERR_PTR(-EPERM);
 
 	root = hugetlbfs_vfsmount->mnt_root;
 	quick_string.name = name;

@@ -952,7 +945,7 @@ struct file *hugetlb_file_setup(const char *name, size_t size,
 	quick_string.hash = 0;
 	path.dentry = d_alloc(root, &quick_string);
 	if (!path.dentry)
-		goto out_shm_unlock;
+		goto out;
 
 	path.mnt = mntget(hugetlbfs_vfsmount);
 	error = -ENOSPC;

@@ -983,11 +976,7 @@ out_inode:
 	iput(inode);
 out_dentry:
 	path_put(&path);
-out_shm_unlock:
-	if (*user) {
-		user_shm_unlock(size, *user);
-		*user = NULL;
-	}
+out:
 	return ERR_PTR(error);
 }

David Rientjes

2011-06-18 23:38 UTC #1 lore raw

Quoted 12 lines · Américo Wang

This is a revert of
commit 2584e517320bd48dc8d20e38a2621a2dbe58fade
Author: Ravikiran G Thirumalai <[email protected]>
Date:   Tue Mar 31 15:21:26 2009 -0700
mm: reintroduce and deprecate rlimit based access for SHM_HUGETLB
because it is deprecated and scheduled to be removed.

I know this is scheduled for removal and it is quite past due, but I think we need to do some due diligence before just yanking the whole thing out. A printk_once() about some mysterious application using SHM_HUGETLB doesn't seem very helpful in migrating users to start using /proc/sys/vm/hugetlb_shm_group, and suddenly returning -EPERM when attempting it doesn't seem very responsible, despite what Documentation/feature-removal-schedule.txt may say.

For context, we just ran into this internally where this warning at one point appeared to be WARN_ON_ONCE(). That seems more attention grabbing because it at least allows users to start understanding what the issue is and who needs to be fixed.

Américo Wang

author

2011-06-23 05:22 UTC #2 lore raw

Quoted 23 lines · David Rientjes

Quoted 12 lines · Américo Wang
This is a revert of
commit 2584e517320bd48dc8d20e38a2621a2dbe58fade
Author: Ravikiran G Thirumalai <[email protected]>
Date: Tue Mar 31 15:21:26 2009 -0700
mm: reintroduce and deprecate rlimit based access for SHM_HUGETLB
because it is deprecated and scheduled to be removed.
I know this is scheduled for removal and it is quite past due, but I think we need to do some due diligence before just yanking the whole thing out. A printk_once() about some mysterious application using SHM_HUGETLB doesn't seem very helpful in migrating users to start using /proc/sys/vm/hugetlb_shm_group, and suddenly returning -EPERM when attempting it doesn't seem very responsible, despite what Documentation/feature-removal-schedule.txt may say.

Quoted 4 lines

For context, we just ran into this internally where this warning at one point appeared to be WARN_ON_ONCE(). That seems more attention grabbing because it at least allows users to start understanding what the issue is and who needs to be fixed.

Well, we put printk_once with KERN_WARNING level, this is already an enough warning, the only difference with WARN_ON_ONCE() is this has no backtrace which is not important for this case.

Thanks.

David Rientjes

NAK

2011-06-23 05:37 UTC #3 lore raw

Quoted 8 lines · Américo Wang

Quoted 8 lines
I know this is scheduled for removal and it is quite past due, but I think we need to do some due diligence before just yanking the whole thing out. A printk_once() about some mysterious application using SHM_HUGETLB doesn't seem very helpful in migrating users to start using /proc/sys/vm/hugetlb_shm_group, and suddenly returning -EPERM when attempting it doesn't seem very responsible, despite what Documentation/feature-removal-schedule.txt may say.

Quoted 9 lines

Quoted 4 lines
For context, we just ran into this internally where this warning at one point appeared to be WARN_ON_ONCE(). That seems more attention grabbing because it at least allows users to start understanding what the issue is and who needs to be fixed.
Well, we put printk_once with KERN_WARNING level, this is already an enough warning, the only difference with WARN_ON_ONCE() is this has no backtrace which is not important for this case.

NACK.

As explained above, using printk_once() to identify that some unidentified application is using SHM_HUGETLB to charge against the mlock rlimit through mmap() isn't sufficient notice and _will_ result in userspace breakage. Please convert this to a WARN_ON_ONCE() so the application is identified, wait 6-12 months, convert it to a WARN_ON(), wait 6-12 months, then remove it.

Thanks.