[Patch] hugetlb: remove user_shm_lock() check from hugetlb_file_setup()

[Patch] hugetlb: remove user_shm_lock() check from hugetlb_file_setup()

[Américo Wang]

This is a revert of

commit 2584e517320bd48dc8d20e38a2621a2dbe58fade
Author: Ravikiran G Thirumalai <kiran@scalex86.org>
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 <mel@csn.ul.ie>
Cc: Ravikiran Thirumalai <kiran@scalex86.org>
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>

---
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 72e2384..d627fd3 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -298,18 +298,6 @@ Who:	Michael Buesch <mb@bu3sch.de>
 
 ---------------------------
 
-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 <kiran@scalex86.org>
-
----------------------------
-
 What:	CONFIG_THERMAL_HWMON
 When:	January 2009
 Why:	This option was introduced just to allow older lm-sensors userspace
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 7aafeb8..e2627a3 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -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);
 }
 

Re: [Patch] hugetlb: remove user_shm_lock() check from hugetlb_file_setup()

[David Rientjes]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1067 bytes --]

On Sat, 18 Jun 2011, Américo Wang wrote:

> 
> This is a revert of
> 
> commit 2584e517320bd48dc8d20e38a2621a2dbe58fade
> Author: Ravikiran G Thirumalai <kiran@scalex86.org>
> 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.

Re: [Patch] hugetlb: remove user_shm_lock() check from hugetlb_file_setup()

[Américo Wang]

On Sun, Jun 19, 2011 at 7:34 AM, David Rientjes <rientjes@google.com> wrote:
> On Sat, 18 Jun 2011, Américo Wang wrote:
>
>>
>> This is a revert of
>>
>> commit 2584e517320bd48dc8d20e38a2621a2dbe58fade
>> Author: Ravikiran G Thirumalai <kiran@scalex86.org>
>> 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.

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.

Re: [Patch] hugetlb: remove user_shm_lock() check from hugetlb_file_setup()

[David Rientjes]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1390 bytes --]

On Thu, 23 Jun 2011, Américo Wang wrote:

> > 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.
> 
> 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.