linux-kernel - Re: [PATCH v8 3/3] mm: reinititalise user and admin reserves if memory is added or removed

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] [day] [month] [year] [list]

Message-ID: <20130409004241.GA4277@localhost.localdomain>
Date:	Mon, 8 Apr 2013 20:42:41 -0400
From:	Andrew Shewmaker <agshew@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	alan@...rguk.ukuu.org.uk, simon.jeons@...il.com,
	ric.masonn@...il.com
Subject: Re: [PATCH v8 3/3] mm: reinititalise user and admin reserves if
 memory is added or removed

On Mon, Apr 08, 2013 at 01:37:12PM -0700, Andrew Morton wrote:
> On Mon, 8 Apr 2013 15:07:38 -0400 Andrew Shewmaker <agshew@...il.com> wrote:
> 
> > This patch alters the admin and user reserves of the previous patches 
> > in this series when memory is added or removed.
> > 
> > If memory is added and the reserves have been eliminated or increased above
> > the default max, then we'll trust the admin.
> > 
> > If memory is removed and there isn't enough free memory, then we
> > need to reset the reserves.
> > 
> > Otherwise keep the reserve set by the admin.
> > 
> > The reserve reset code is the same as the reserve initialization code.
> > 
> > Does this sound reasonable to other people? I figured that hot removal
> > with too large of memory in the reserves was the most important case 
> > to get right.
> 
> Seems reasonable to me.
> 
> I don't understand the magic numbers 1<<13 and 1<<17.  How could I? 
> Please add comments explaining how and why these were chosen.

The v9 patch I posted has this too, but here is a patch against 
yesterday's mmotm.

diff --git a/mm/mmap.c b/mm/mmap.c
index 099a16d..cee7e74 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -3119,6 +3119,13 @@ module_init(init_admin_reserve)
 /*
  * Reinititalise user and admin reserves if memory is added or removed.
  *
+ * The default user reserve max is 128MB, and the default max for the
+ * admin reserve is 8MB. These are usually, but not always, enough to
+ * enable recovery from a memory hogging process using login/sshd, a shell,
+ * and tools like top. It may make sense to increase or even disable the
+ * reserve depending on the existence of swap or variations in the recovery
+ * tools. So, the admin may have changed them.
+ *
  * If memory is added and the reserves have been eliminated or increased above
  * the default max, then we'll trust the admin.
  *
@@ -3134,10 +3141,16 @@ static int reserve_mem_notifier(struct notifier_block *nb,
 
 	switch (action) {
 	case MEM_ONLINE:
+		/*
+		 * Default max is 128MB. Leave alone if modified by operator.
+ 		 */
 		tmp = sysctl_user_reserve_kbytes;
 		if (0 < tmp && tmp < (1UL << 17))
 			init_user_reserve();
 
+		/*
+		 * Default max is 8MB. Leave alone if modified by operator.
+ 		 */
 		tmp = sysctl_admin_reserve_kbytes;
 		if (0 < tmp && tmp < (1UL << 13))
 			init_admin_reserve();
--
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/