lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 23 Feb 2009 11:21:56 +0000
From:	Mel Gorman <mel@....ul.ie>
To:	Ravikiran G Thirumalai <kiran@...lex86.org>
Cc:	akpm@...ux-foundation.org, wli@...ementarian.org,
	linux-mm@...ck.org, shai@...lex86.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 2/2] mm: Reintroduce and deprecate rlimit based access
	for SHM_HUGETLB

On Fri, Feb 20, 2009 at 05:57:48PM -0800, Ravikiran G Thirumalai wrote:
> 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.
> 
> Signed-off-by: Ravikiran Thirumalai <kiran@...lex86.org>
> Cc: Mel Gorman <mel@....ul.ie>
> Cc: Wli <wli@...ementarian.org>
> 
> Index: linux-2.6-tip/fs/hugetlbfs/inode.c
> ===================================================================
> --- linux-2.6-tip.orig/fs/hugetlbfs/inode.c	2009-02-10 13:30:05.000000000 -0800
> +++ linux-2.6-tip/fs/hugetlbfs/inode.c	2009-02-11 21:58:23.000000000 -0800
> @@ -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 ch
>  	if (!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);
> +	}
>  

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.

>  	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);
>  }
>  
> Index: linux-2.6-tip/Documentation/feature-removal-schedule.txt
> ===================================================================
> --- linux-2.6-tip.orig/Documentation/feature-removal-schedule.txt	2009-02-09 16:45:47.000000000 -0800
> +++ linux-2.6-tip/Documentation/feature-removal-schedule.txt	2009-02-11 21:35:28.000000000 -0800
> @@ -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 <paul.moore@...com>
> +---------------------------
> +
> +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@...lex86.org>
> 

Reviewed-by: Mel Gorman <mel@....ul.ie>

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ