Skip to contentSkip to conversation

do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY

PATCH In review Herbert van den Bergh 2 participants 4 messages Jul 10, 2007 – Jul 13, 2007

Subsystems (2)
Memory management Memory mapping
lore
Share & tools
lore

Herbert van den Bergh

author
#0 lore raw

PATCH 1/1 do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY

[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 <[email protected]>
Acked-by Chris Mason <[email protected]>
mm/mlock.c renamed from mm/mlock.c.orig +4 -1
@@ -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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

maintainer
#1 lore raw
Quoted 17 lines · On Mon, 09 Jul 2007 17:59:12 -0700 Herbert van den Bergh…

[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 <[email protected]>
Acked-by Chris Mason <[email protected]>
mm/mlock.c renamed from mm/mlock.c.orig +0 -0
@@ -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;

mm/mlock.c int user_shm_lock(size_t size, struct us · line 255

Quoted 10 lines
mm/mlock.c renamed from mm/mlock.c.orig +4 -1
+	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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

maintainer
#3 lore raw
Quoted 8 lines · On Fri, 13 Jul 2007 08:37:50 -0700 Herbert van den Bergh…
Quoted 4 lines · Andrew Morton

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: <[email protected]>" 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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>