All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: zhe.he@windriver.com
Cc: sergey.senozhatsky@gmail.com, rostedt@goodmis.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 4/4] printk: Give error on attempt to set log buffer length to over 4G
Date: Mon, 8 Oct 2018 15:59:16 +0200	[thread overview]
Message-ID: <20181008135916.gg4kkmoki5bgtco5@pathway.suse.cz> (raw)
In-Reply-To: <1538239553-81805-4-git-send-email-zhe.he@windriver.com>

On Sun 2018-09-30 00:45:53, zhe.he@windriver.com wrote:
> From: He Zhe <zhe.he@windriver.com>
> 
> Give explicit error for users who want to use larger log buffer.
> 
> Signed-off-by: He Zhe <zhe.he@windriver.com>
> Cc: pmladek@suse.com
> Cc: sergey.senozhatsky@gmail.com
> Cc: rostedt@goodmis.org
> ---
>  kernel/printk/printk.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index b84aac0..5ccfd5d 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1039,18 +1039,23 @@ void log_buf_vmcoreinfo_setup(void)
>  static unsigned long __initdata new_log_buf_len;
>  
>  /* we practice scaling the ring buffer by powers of 2 */
> -static void __init log_buf_len_update(unsigned size)
> +static void __init log_buf_len_update(u64 size)
>  {
> +	if (size > UINT_MAX) {
> +		size = UINT_MAX;
> +		pr_err("log_buf over 4G is not supported.\n");

I tried this patch with log_buf_len=5G. The kernel did not crash
but dmesg shown some mess. There are several 32-bit variables
to store the size, for example:

static u32 log_buf_len = __LOG_BUF_LEN;
u32 log_buf_len_get(void)
static u32 log_first_idx;
static u32 log_next_idx;

I guess that the code somewhere does not detect an overflows
correctly.

I am not motivated enought to add support for such huge message
buffer. Therefore I suggest to limit it to 32G for now.

This patch worked for me:


From d63b781b596ccb3d205801b2ba944797fa7ab0ce Mon Sep 17 00:00:00 2001
From: He Zhe <zhe.he@windriver.com>
Date: Sun, 30 Sep 2018 00:45:53 +0800
Subject: [PATCH] printk: Give error on attempt to set log buffer length to
 over 2G

The current printk() is ready to handle log buffer size up to 2G.
Give an explicit error for users who want to use larger log buffer.

Also fix printk formatting to show the 2G as a positive number.

Suggested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
 kernel/printk/printk.c | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 15f3e70be448..f595107ddf42 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1040,18 +1040,23 @@ void log_buf_vmcoreinfo_setup(void)
 static unsigned long __initdata new_log_buf_len;
 
 /* we practice scaling the ring buffer by powers of 2 */
-static void __init log_buf_len_update(unsigned size)
+static void __init log_buf_len_update(u64 size)
 {
+	if (size > UINT_MAX) {
+		size = UINT_MAX;
+		pr_err("log_buf over 2G is not supported.\n");
+	}
+
 	if (size)
 		size = roundup_pow_of_two(size);
 	if (size > log_buf_len)
-		new_log_buf_len = size;
+		new_log_buf_len = (unsigned long)size;
 }
 
 /* save requested log_buf_len since it's too early to process it */
 static int __init log_buf_len_setup(char *str)
 {
-	unsigned int size;
+	u64 size;
 
 	if (!str)
 		return -EINVAL;
@@ -1121,7 +1126,7 @@ void __init setup_log_buf(int early)
 	}
 
 	if (unlikely(!new_log_buf)) {
-		pr_err("log_buf_len: %ld bytes not available\n",
+		pr_err("log_buf_len: %lu bytes not available\n",
 			new_log_buf_len);
 		return;
 	}
@@ -1134,8 +1139,8 @@ void __init setup_log_buf(int early)
 	memcpy(log_buf, __log_buf, __LOG_BUF_LEN);
 	logbuf_unlock_irqrestore(flags);
 
-	pr_info("log_buf_len: %d bytes\n", log_buf_len);
-	pr_info("early log buf free: %d(%d%%)\n",
+	pr_info("log_buf_len: %u bytes\n", log_buf_len);
+	pr_info("early log buf free: %u(%u%%)\n",
 		free, (free * 100) / __LOG_BUF_LEN);
 }
 
-- 
2.13.7


  parent reply	other threads:[~2018-10-08 13:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-29 16:45 [PATCH v5 1/4] printk: Fix panic caused by passing log_buf_len to command line zhe.he
2018-09-29 16:45 ` [PATCH v5 2/4] printk: Correct wrong casting zhe.he
2018-10-02  5:50   ` Sergey Senozhatsky
2018-10-08 13:03     ` Petr Mladek
2018-09-29 16:45 ` [PATCH v5 3/4] printk: Add KBUILD_MODNAME and remove a redundant print prefix zhe.he
2018-10-02  5:52   ` Sergey Senozhatsky
2018-10-08 13:04   ` Petr Mladek
2018-09-29 16:45 ` [PATCH v5 4/4] printk: Give error on attempt to set log buffer length to over 4G zhe.he
2018-10-02  5:51   ` Sergey Senozhatsky
2018-10-08 13:59   ` Petr Mladek [this message]
2018-10-08 14:59     ` Sergey Senozhatsky
2018-10-09 13:05       ` Petr Mladek
2018-10-09 13:57         ` Sergey Senozhatsky
2018-10-10  8:09           ` Petr Mladek
2018-10-10  8:21             ` Sergey Senozhatsky
2018-10-08 16:30     ` He Zhe
2018-10-02  5:48 ` [PATCH v5 1/4] printk: Fix panic caused by passing log_buf_len to command line Sergey Senozhatsky
2018-10-08 13:01 ` Petr Mladek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181008135916.gg4kkmoki5bgtco5@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=zhe.he@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.