linux-kernel - [PATCH v8 2/4] printk: move power of 2 practice of ring buffer size to a helper

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:	Wed, 18 Jun 2014 13:45:35 -0700
From:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>
To:	gregkh@...uxfoundation.org, akpm@...ux-foundation.org,
	hpa@...ux.intel.com
Cc:	linux-kernel@...r.kernel.org,
	"Luis R. Rodriguez" <mcgrof@...e.com>,
	Andrew Lunn <andrew@...n.ch>,
	Stephen Warren <swarren@...dotorg.org>,
	Michal Hocko <mhocko@...e.cz>, Petr Mladek <pmladek@...e.cz>,
	Joe Perches <joe@...ches.com>,
	Arun KS <arunks.linux@...il.com>,
	Kees Cook <keescook@...omium.org>,
	Davidlohr Bueso <davidlohr@...com>,
	Chris Metcalf <cmetcalf@...era.com>
Subject: [PATCH v8 2/4] printk: move power of 2 practice of ring buffer size to a helper

From: "Luis R. Rodriguez" <mcgrof@...e.com>

In practice the power of 2 practice of the size of the kernel ring
buffer remains purely historical but not a requirement, specially
now that we have LOG_ALIGN and use it for both static and dynamic
allocations. It could have helped with implicit alignment back in
the days given the even the dynamically sized ring buffer was
guaranteed to be aligned so long as CONFIG_LOG_BUF_SHIFT was set to
produce a __LOG_BUF_LEN which is architecture aligned, since
log_buf_len=n would be allowed only if it was > __LOG_BUF_LEN and
we always ended up rounding the log_buf_len=n to the next power
of 2 with roundup_pow_of_two(), any multiple of 2 then should be also
architecture aligned. These assumptions of course relied heavily
on CONFIG_LOG_BUF_SHIFT producing an aligned value but users can
always change this.

We now have precise alignment requirements set for the log buffer
size for both static and dynamic allocations, but lets upkeep the
old practice of using powers of 2 for its size to help with easy
expected scalable values and the allocators for dynamic allocations.
We'll reuse this later so move this into a helper.

Cc: Andrew Lunn <andrew@...n.ch>
Cc: Stephen Warren <swarren@...dotorg.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Michal Hocko <mhocko@...e.cz>
Cc: Petr Mladek <pmladek@...e.cz>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: Joe Perches <joe@...ches.com>
Cc: Arun KS <arunks.linux@...il.com>
Cc: Kees Cook <keescook@...omium.org>
Cc: Davidlohr Bueso <davidlohr@...com>
Cc: Chris Metcalf <cmetcalf@...era.com>
Cc: linux-kernel@...r.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@...e.com>
---
 kernel/printk/printk.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 78ceccf..af164a7 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -828,15 +828,21 @@ void log_buf_kexec_setup(void)
 /* requested log_buf_len from kernel cmdline */
 static unsigned long __initdata new_log_buf_len;

-/* save requested log_buf_len since it's too early to process it */
-static int __init log_buf_len_setup(char *str)
+/* we practice scaling the ring buffer by powers of 2 */
+static void __init log_buf_len_update(unsigned size)
 {
-	unsigned size = memparse(str, &str);
-
 	if (size)
 		size = roundup_pow_of_two(size);
 	if (size > log_buf_len)
 		new_log_buf_len = size;
+}
+
+/* save requested log_buf_len since it's too early to process it */
+static int __init log_buf_len_setup(char *str)
+{
+	unsigned size = memparse(str, &str);
+
+	log_buf_len_update(size);

 	return 0;
 }
-- 
1.9.3

--
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/