* [PATCH] do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY
@ 2007-07-10 0:26 ` Herbert van den Bergh
0 siblings, 0 replies; 15+ messages in thread
From: Herbert van den Bergh @ 2007-07-10 0:26 UTC (permalink / raw)
To: linux-kernel, linux-mm; +Cc: akpm, Dave McCracken, Chris Mason
This patch fixes a bug in mm/mlock.c on 32-bit architectures that prevents
a user from locking more than 4GB of shared memory, or allocating more
than 4GB of shared memory in hugepages, when rlim[RLIMIT_MEMLOCK] is
set to RLIM_INFINITY.
Signed-off-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
Acked-by: Chris Mason <chris.mason@oracle.com>
--- linux-2.6.22/mm/mlock.c.orig 2007-07-09 10:19:31.000000000 -0700
+++ linux-2.6.22/mm/mlock.c 2007-07-09 10:19:19.000000000 -0700
@@ -244,9 +244,12 @@ int user_shm_lock(size_t size, struct us
locked = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
lock_limit = current->signal->rlim[RLIMIT_MEMLOCK].rlim_cur;
+ if (lock_limit == RLIM_INFINITY)
+ allowed = 1;
lock_limit >>= PAGE_SHIFT;
spin_lock(&shmlock_user_lock);
- if (locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
+ if (!allowed &&
+ locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
goto out;
get_uid(user);
user->locked_shm += locked;
^ permalink raw reply [flat|nested] 15+ messages in thread* [PATCH] do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY
@ 2007-07-10 0:26 ` Herbert van den Bergh
0 siblings, 0 replies; 15+ messages in thread
From: Herbert van den Bergh @ 2007-07-10 0:26 UTC (permalink / raw)
To: linux-kernel, linux-mm; +Cc: akpm, Dave McCracken, Chris Mason
This patch fixes a bug in mm/mlock.c on 32-bit architectures that prevents
a user from locking more than 4GB of shared memory, or allocating more
than 4GB of shared memory in hugepages, when rlim[RLIMIT_MEMLOCK] is
set to RLIM_INFINITY.
Signed-off-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
Acked-by: Chris Mason <chris.mason@oracle.com>
--- linux-2.6.22/mm/mlock.c.orig 2007-07-09 10:19:31.000000000 -0700
+++ linux-2.6.22/mm/mlock.c 2007-07-09 10:19:19.000000000 -0700
@@ -244,9 +244,12 @@ int user_shm_lock(size_t size, struct us
locked = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
lock_limit = current->signal->rlim[RLIMIT_MEMLOCK].rlim_cur;
+ if (lock_limit == RLIM_INFINITY)
+ allowed = 1;
lock_limit >>= PAGE_SHIFT;
spin_lock(&shmlock_user_lock);
- if (locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
+ if (!allowed &&
+ locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
goto out;
get_uid(user);
user->locked_shm += locked;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH] do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY
2007-07-10 0:26 ` Herbert van den Bergh
@ 2007-07-10 0:41 ` KAMEZAWA Hiroyuki
-1 siblings, 0 replies; 15+ messages in thread
From: KAMEZAWA Hiroyuki @ 2007-07-10 0:41 UTC (permalink / raw)
To: Herbert van den Bergh
Cc: linux-kernel, linux-mm, akpm, Dave McCracken, Chris Mason
On Mon, 09 Jul 2007 17:26:24 -0700
Herbert van den Bergh <Herbert.van.den.Bergh@oracle.com> wrote:
>
> This patch fixes a bug in mm/mlock.c on 32-bit architectures that prevents
> a user from locking more than 4GB of shared memory, or allocating more
> than 4GB of shared memory in hugepages, when rlim[RLIMIT_MEMLOCK] is
> set to RLIM_INFINITY.
>
just curious...why a resouce which can be used longer than a process's
lifetime is limited by RLIMIT ?
Thanks,
-Kame
> Signed-off-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
> Acked-by: Chris Mason <chris.mason@oracle.com>
>
> --- linux-2.6.22/mm/mlock.c.orig 2007-07-09 10:19:31.000000000 -0700
> +++ linux-2.6.22/mm/mlock.c 2007-07-09 10:19:19.000000000 -0700
> @@ -244,9 +244,12 @@ int user_shm_lock(size_t size, struct us
>
> locked = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> lock_limit = current->signal->rlim[RLIMIT_MEMLOCK].rlim_cur;
> + if (lock_limit == RLIM_INFINITY)
> + allowed = 1;
> lock_limit >>= PAGE_SHIFT;
> spin_lock(&shmlock_user_lock);
> - if (locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
> + if (!allowed &&
> + locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
> goto out;
> get_uid(user);
> user->locked_shm += locked;
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY
@ 2007-07-10 0:41 ` KAMEZAWA Hiroyuki
0 siblings, 0 replies; 15+ messages in thread
From: KAMEZAWA Hiroyuki @ 2007-07-10 0:41 UTC (permalink / raw)
To: Herbert van den Bergh
Cc: linux-kernel, linux-mm, akpm, Dave McCracken, Chris Mason
On Mon, 09 Jul 2007 17:26:24 -0700
Herbert van den Bergh <Herbert.van.den.Bergh@oracle.com> wrote:
>
> This patch fixes a bug in mm/mlock.c on 32-bit architectures that prevents
> a user from locking more than 4GB of shared memory, or allocating more
> than 4GB of shared memory in hugepages, when rlim[RLIMIT_MEMLOCK] is
> set to RLIM_INFINITY.
>
just curious...why a resouce which can be used longer than a process's
lifetime is limited by RLIMIT ?
Thanks,
-Kame
> Signed-off-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
> Acked-by: Chris Mason <chris.mason@oracle.com>
>
> --- linux-2.6.22/mm/mlock.c.orig 2007-07-09 10:19:31.000000000 -0700
> +++ linux-2.6.22/mm/mlock.c 2007-07-09 10:19:19.000000000 -0700
> @@ -244,9 +244,12 @@ int user_shm_lock(size_t size, struct us
>
> locked = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> lock_limit = current->signal->rlim[RLIMIT_MEMLOCK].rlim_cur;
> + if (lock_limit == RLIM_INFINITY)
> + allowed = 1;
> lock_limit >>= PAGE_SHIFT;
> spin_lock(&shmlock_user_lock);
> - if (locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
> + if (!allowed &&
> + locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
> goto out;
> get_uid(user);
> user->locked_shm += locked;
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY
2007-07-10 0:26 ` Herbert van den Bergh
@ 2007-07-10 0:47 ` Randy Dunlap
-1 siblings, 0 replies; 15+ messages in thread
From: Randy Dunlap @ 2007-07-10 0:47 UTC (permalink / raw)
To: Herbert van den Bergh
Cc: linux-kernel, linux-mm, akpm, Dave McCracken, Chris Mason
On Mon, 09 Jul 2007 17:26:24 -0700 Herbert van den Bergh wrote:
>
> This patch fixes a bug in mm/mlock.c on 32-bit architectures that prevents
> a user from locking more than 4GB of shared memory, or allocating more
> than 4GB of shared memory in hugepages, when rlim[RLIMIT_MEMLOCK] is
> set to RLIM_INFINITY.
Something has converted tabs to spaces in your patch.
Ah, thunderbird. Did you use an external editor plugin?
If not, did you use preformat and other instructions from
http://mbligh.org/linuxdocs/Email/Clients/Thunderbird ?
Please send a patch to yourself and make sure that you can apply
the received patch cleanly.
> Signed-off-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
> Acked-by: Chris Mason <chris.mason@oracle.com>
>
> --- linux-2.6.22/mm/mlock.c.orig 2007-07-09 10:19:31.000000000 -0700
> +++ linux-2.6.22/mm/mlock.c 2007-07-09 10:19:19.000000000 -0700
> @@ -244,9 +244,12 @@ int user_shm_lock(size_t size, struct us
>
> locked = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> lock_limit = current->signal->rlim[RLIMIT_MEMLOCK].rlim_cur;
> + if (lock_limit == RLIM_INFINITY)
> + allowed = 1;
> lock_limit >>= PAGE_SHIFT;
> spin_lock(&shmlock_user_lock);
> - if (locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
> + if (!allowed &&
> + locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
> goto out;
> get_uid(user);
> user->locked_shm += locked;
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY
@ 2007-07-10 0:47 ` Randy Dunlap
0 siblings, 0 replies; 15+ messages in thread
From: Randy Dunlap @ 2007-07-10 0:47 UTC (permalink / raw)
To: Herbert van den Bergh
Cc: linux-kernel, linux-mm, akpm, Dave McCracken, Chris Mason
On Mon, 09 Jul 2007 17:26:24 -0700 Herbert van den Bergh wrote:
>
> This patch fixes a bug in mm/mlock.c on 32-bit architectures that prevents
> a user from locking more than 4GB of shared memory, or allocating more
> than 4GB of shared memory in hugepages, when rlim[RLIMIT_MEMLOCK] is
> set to RLIM_INFINITY.
Something has converted tabs to spaces in your patch.
Ah, thunderbird. Did you use an external editor plugin?
If not, did you use preformat and other instructions from
http://mbligh.org/linuxdocs/Email/Clients/Thunderbird ?
Please send a patch to yourself and make sure that you can apply
the received patch cleanly.
> Signed-off-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
> Acked-by: Chris Mason <chris.mason@oracle.com>
>
> --- linux-2.6.22/mm/mlock.c.orig 2007-07-09 10:19:31.000000000 -0700
> +++ linux-2.6.22/mm/mlock.c 2007-07-09 10:19:19.000000000 -0700
> @@ -244,9 +244,12 @@ int user_shm_lock(size_t size, struct us
>
> locked = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> lock_limit = current->signal->rlim[RLIMIT_MEMLOCK].rlim_cur;
> + if (lock_limit == RLIM_INFINITY)
> + allowed = 1;
> lock_limit >>= PAGE_SHIFT;
> spin_lock(&shmlock_user_lock);
> - if (locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
> + if (!allowed &&
> + locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
> goto out;
> get_uid(user);
> user->locked_shm += locked;
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH] do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY
@ 2007-07-10 0:59 ` Herbert van den Bergh
0 siblings, 0 replies; 15+ messages in thread
From: Herbert van den Bergh @ 2007-07-10 0:59 UTC (permalink / raw)
To: linux-kernel, linux-mm; +Cc: akpm, Dave McCracken, Chris Mason
[resending, since my previous message had tabs converted to spaces]
This patch fixes a bug in mm/mlock.c on 32-bit architectures that prevents
a user from locking more than 4GB of shared memory, or allocating more
than 4GB of shared memory in hugepages, when rlim[RLIMIT_MEMLOCK] is
set to RLIM_INFINITY.
Signed-off-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
Acked-by: Chris Mason <chris.mason@oracle.com>
--- linux-2.6.22/mm/mlock.c.orig 2007-07-09 10:19:31.000000000 -0700
+++ linux-2.6.22/mm/mlock.c 2007-07-09 10:19:19.000000000 -0700
@@ -244,9 +244,12 @@ int user_shm_lock(size_t size, struct us
locked = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
lock_limit = current->signal->rlim[RLIMIT_MEMLOCK].rlim_cur;
+ if (lock_limit == RLIM_INFINITY)
+ allowed = 1;
lock_limit >>= PAGE_SHIFT;
spin_lock(&shmlock_user_lock);
- if (locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
+ if (!allowed &&
+ locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
goto out;
get_uid(user);
user->locked_shm += locked;
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH] do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY
@ 2007-07-10 0:59 ` Herbert van den Bergh
0 siblings, 0 replies; 15+ messages in thread
From: Herbert van den Bergh @ 2007-07-10 0:59 UTC (permalink / raw)
To: linux-kernel, linux-mm; +Cc: akpm, Dave McCracken, Chris Mason
[resending, since my previous message had tabs converted to spaces]
This patch fixes a bug in mm/mlock.c on 32-bit architectures that prevents
a user from locking more than 4GB of shared memory, or allocating more
than 4GB of shared memory in hugepages, when rlim[RLIMIT_MEMLOCK] is
set to RLIM_INFINITY.
Signed-off-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
Acked-by: Chris Mason <chris.mason@oracle.com>
--- linux-2.6.22/mm/mlock.c.orig 2007-07-09 10:19:31.000000000 -0700
+++ linux-2.6.22/mm/mlock.c 2007-07-09 10:19:19.000000000 -0700
@@ -244,9 +244,12 @@ int user_shm_lock(size_t size, struct us
locked = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
lock_limit = current->signal->rlim[RLIMIT_MEMLOCK].rlim_cur;
+ if (lock_limit == RLIM_INFINITY)
+ allowed = 1;
lock_limit >>= PAGE_SHIFT;
spin_lock(&shmlock_user_lock);
- if (locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
+ if (!allowed &&
+ locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
goto out;
get_uid(user);
user->locked_shm += locked;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY
2007-07-10 0:59 ` Herbert van den Bergh
@ 2007-07-13 7:44 ` Andrew Morton
-1 siblings, 0 replies; 15+ messages in thread
From: Andrew Morton @ 2007-07-13 7:44 UTC (permalink / raw)
To: Herbert van den Bergh; +Cc: linux-kernel, linux-mm, Dave McCracken, Chris Mason
On Mon, 09 Jul 2007 17:59:12 -0700 Herbert van den Bergh <Herbert.van.den.Bergh@oracle.com> wrote:
>
> [resending, since my previous message had tabs converted to spaces]
>
> This patch fixes a bug in mm/mlock.c on 32-bit architectures that prevents
> a user from locking more than 4GB of shared memory, or allocating more
> than 4GB of shared memory in hugepages, when rlim[RLIMIT_MEMLOCK] is
> set to RLIM_INFINITY.
>
> Signed-off-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
> Acked-by: Chris Mason <chris.mason@oracle.com>
>
> --- linux-2.6.22/mm/mlock.c.orig 2007-07-09 10:19:31.000000000 -0700
> +++ linux-2.6.22/mm/mlock.c 2007-07-09 10:19:19.000000000 -0700
> @@ -244,9 +244,12 @@ int user_shm_lock(size_t size, struct us
>
> locked = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> lock_limit = current->signal->rlim[RLIMIT_MEMLOCK].rlim_cur;
> + if (lock_limit == RLIM_INFINITY)
> + allowed = 1;
> lock_limit >>= PAGE_SHIFT;
> spin_lock(&shmlock_user_lock);
> - if (locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
> + if (!allowed &&
> + locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
> goto out;
> get_uid(user);
> user->locked_shm += locked;
OK. Seems like a nasty bug if one happens to want to do that. Should we
backport this into 2.6.22.x?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY
@ 2007-07-13 7:44 ` Andrew Morton
0 siblings, 0 replies; 15+ messages in thread
From: Andrew Morton @ 2007-07-13 7:44 UTC (permalink / raw)
To: Herbert van den Bergh; +Cc: linux-kernel, linux-mm, Dave McCracken, Chris Mason
On Mon, 09 Jul 2007 17:59:12 -0700 Herbert van den Bergh <Herbert.van.den.Bergh@oracle.com> wrote:
>
> [resending, since my previous message had tabs converted to spaces]
>
> This patch fixes a bug in mm/mlock.c on 32-bit architectures that prevents
> a user from locking more than 4GB of shared memory, or allocating more
> than 4GB of shared memory in hugepages, when rlim[RLIMIT_MEMLOCK] is
> set to RLIM_INFINITY.
>
> Signed-off-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
> Acked-by: Chris Mason <chris.mason@oracle.com>
>
> --- linux-2.6.22/mm/mlock.c.orig 2007-07-09 10:19:31.000000000 -0700
> +++ linux-2.6.22/mm/mlock.c 2007-07-09 10:19:19.000000000 -0700
> @@ -244,9 +244,12 @@ int user_shm_lock(size_t size, struct us
>
> locked = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> lock_limit = current->signal->rlim[RLIMIT_MEMLOCK].rlim_cur;
> + if (lock_limit == RLIM_INFINITY)
> + allowed = 1;
> lock_limit >>= PAGE_SHIFT;
> spin_lock(&shmlock_user_lock);
> - if (locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
> + if (!allowed &&
> + locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
> goto out;
> get_uid(user);
> user->locked_shm += locked;
OK. Seems like a nasty bug if one happens to want to do that. Should we
backport this into 2.6.22.x?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY
2007-07-13 7:44 ` Andrew Morton
@ 2007-07-13 15:37 ` Herbert van den Bergh
-1 siblings, 0 replies; 15+ messages in thread
From: Herbert van den Bergh @ 2007-07-13 15:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm, Dave McCracken, Chris Mason
Andrew Morton wrote:
>
> OK. Seems like a nasty bug if one happens to want to do that. Should we
> backport this into 2.6.22.x?
>
Yes, please. Do you need me to do anything for that?
Thanks,
Herbert.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY
@ 2007-07-13 15:37 ` Herbert van den Bergh
0 siblings, 0 replies; 15+ messages in thread
From: Herbert van den Bergh @ 2007-07-13 15:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm, Dave McCracken, Chris Mason
Andrew Morton wrote:
>
> OK. Seems like a nasty bug if one happens to want to do that. Should we
> backport this into 2.6.22.x?
>
Yes, please. Do you need me to do anything for that?
Thanks,
Herbert.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY
2007-07-13 15:37 ` Herbert van den Bergh
@ 2007-07-13 17:31 ` Andrew Morton
-1 siblings, 0 replies; 15+ messages in thread
From: Andrew Morton @ 2007-07-13 17:31 UTC (permalink / raw)
To: Herbert van den Bergh; +Cc: linux-kernel, linux-mm, Dave McCracken, Chris Mason
On Fri, 13 Jul 2007 08:37:50 -0700 Herbert van den Bergh <herbert.van.den.bergh@oracle.com> wrote:
> Andrew Morton wrote:
> >
> > OK. Seems like a nasty bug if one happens to want to do that. Should we
> > backport this into 2.6.22.x?
> >
>
> Yes, please. Do you need me to do anything for that?
>
Nope. I stick a "Cc: <stable@kernel.org>" into the changelog and then
magic happens: the -stable maintainers get a copy of the patch when it goes
to Linus, they get notification when I drop it after Linus merged it and
then they (hopeully) take the patch from Linus's tree.
(But the last step is a bit of a hassle - I suspect they take my emailed
version instead, but it would be super-rare for that to differ from the
version which Linus merged)
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY
@ 2007-07-13 17:31 ` Andrew Morton
0 siblings, 0 replies; 15+ messages in thread
From: Andrew Morton @ 2007-07-13 17:31 UTC (permalink / raw)
To: Herbert van den Bergh; +Cc: linux-kernel, linux-mm, Dave McCracken, Chris Mason
On Fri, 13 Jul 2007 08:37:50 -0700 Herbert van den Bergh <herbert.van.den.bergh@oracle.com> wrote:
> Andrew Morton wrote:
> >
> > OK. Seems like a nasty bug if one happens to want to do that. Should we
> > backport this into 2.6.22.x?
> >
>
> Yes, please. Do you need me to do anything for that?
>
Nope. I stick a "Cc: <stable@kernel.org>" into the changelog and then
magic happens: the -stable maintainers get a copy of the patch when it goes
to Linus, they get notification when I drop it after Linus merged it and
then they (hopeully) take the patch from Linus's tree.
(But the last step is a bit of a hassle - I suspect they take my emailed
version instead, but it would be super-rare for that to differ from the
version which Linus merged)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH] do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY
@ 2007-06-28 18:25 Herbert van den Bergh
0 siblings, 0 replies; 15+ messages in thread
From: Herbert van den Bergh @ 2007-06-28 18:25 UTC (permalink / raw)
To: linux-mm
This patch fixes a bug in mm/mlock.c on 32-bit architectures that prevents
a user from locking more than 4GB of shared memory, or allocating more
than 4GB of shared memory in hugepages, when rlim[RLIMIT_MEMLOCK] is
set to RLIM_INFINITY.
Signed-off-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
Acked-by: Chris Mason <chris.mason@oracle.com>
--- linux-2.6.22-rc6/mm/mlock.c.orig 2007-06-26 15:17:22.000000000 -0700
+++ linux-2.6.22-rc6/mm/mlock.c 2007-06-28 11:18:48.000000000 -0700
@@ -244,9 +244,12 @@ int user_shm_lock(size_t size, struct us
locked = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
lock_limit = current->signal->rlim[RLIMIT_MEMLOCK].rlim_cur;
+ if (lock_limit == RLIM_INFINITY)
+ allowed = 1;
lock_limit >>= PAGE_SHIFT;
spin_lock(&shmlock_user_lock);
- if (locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
+ if (!allowed &&
+ locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
goto out;
get_uid(user);
user->locked_shm += locked;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2007-07-13 17:32 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-07-10 0:26 [PATCH] do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY Herbert van den Bergh
2007-07-10 0:26 ` Herbert van den Bergh
2007-07-10 0:41 ` KAMEZAWA Hiroyuki
2007-07-10 0:41 ` KAMEZAWA Hiroyuki
2007-07-10 0:47 ` Randy Dunlap
2007-07-10 0:47 ` Randy Dunlap
-- strict thread matches above, loose matches on Subject: below --
2007-07-10 0:59 Herbert van den Bergh
2007-07-10 0:59 ` Herbert van den Bergh
2007-07-13 7:44 ` Andrew Morton
2007-07-13 7:44 ` Andrew Morton
2007-07-13 15:37 ` Herbert van den Bergh
2007-07-13 15:37 ` Herbert van den Bergh
2007-07-13 17:31 ` Andrew Morton
2007-07-13 17:31 ` Andrew Morton
2007-06-28 18:25 Herbert van den Bergh
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.