[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090206012858.GB8946@localdomain>
Date: Thu, 5 Feb 2009 17:28:58 -0800
From: Ravikiran G Thirumalai <kiran@...lex86.org>
To: wli@...ementarian.org
Cc: Mel Gorman <mel@....ul.ie>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org, shai@...lex86.org
Subject: Re: [patch] mm: Fix SHM_HUGETLB to work with users in
hugetlb_shm_group
On Thu, Feb 05, 2009 at 06:32:57PM -0500, wli@...ementarian.org wrote:
>On Thu, Feb 05, 2009 at 11:08:51AM -0800, Ravikiran G Thirumalai wrote:
>> I totally agree. In fact yesterday I was thinking of resending
>> this patch to not account for shm memory when a user is not
>> validated against rlimits (when he has CAP_IPC_LOCK or if he
>> belongs to the sysctl_hugetlb_shm_group).
>> As I see it there must be two parts:
>> 1. Free ticket to CAP_IPC_LOCK and users belonging to
>> sysctl_hugetlb_shm_group
>> 2. Patch to have users not having CAP_IPC_LOCK or
>> sysctl_hugetlb_shm_group to check against memlock
>> rlimits, and account it. Also mark this deprecated in
>> feature-removal-schedule.txt
>> Would this be OK?
>
>This is the ideal scenario, except I thought the rlimit was destined
>to replace the other methods, not vice-versa. I don't really mind
>going this way, but maybe we should check in with the rlimit authors.
RLIMIT_MEMLOCK for SHM_HUGETLB seems bad and unrelated! And as Mel rightly
pointed out, currently rlimits are checked for hugetlb shm but not for
hugetlb mmaps. Unless whoever authored the rlimit limitation comes forward
with a good explanation, I think it should be deprecated.
--
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