Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3616749imm; Mon, 8 Oct 2018 06:59:43 -0700 (PDT) X-Google-Smtp-Source: ACcGV61k9ku0vLEof6ZXLiL1jv3yzUsnHu2/aJJoRkkmP9IROtCxLjUsfSTE7kV+3RRxzMVi2wBW X-Received: by 2002:aa7:8252:: with SMTP id e18-v6mr20804723pfn.164.1539007183088; Mon, 08 Oct 2018 06:59:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539007183; cv=none; d=google.com; s=arc-20160816; b=omVBbakYGuEnLI1Ek6yIWiVAC4XFDHOD3odpruHLvy8dqqNiCFtdhJeblfPlV1gw4T 7pRG9hdwbcaQ+1oMusoSkZNXbs6oVrBd0EOc0ijR/sxwzYhxI/fcv7zgbXh8Q1ifMOXq 6u2rK+womPUy/LfQCj/uBA9SsKnKnot2fqLdmra8zUSk0amW3glJ6nR4mLwQeW7fZNZm +VuYNggbCZGaq9VFAgbWI7Ne92nZ33U4WK1c4SPitcVnn7yqdESrb8qCa/2apimQ20bl OVEEl1v3ZBSCXcrXQkEvUfrg2OtZSn2/TQKZEXlwzQkkpNp4ovIKepY1Xpk4qKU1IaQK 4mSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ysNwtyDILiPB6jLzm+FFFq7yyoP8E99zhVW3qPNKwcQ=; b=IHj7kyK/ZLVXnOQEEizEhS4usBkNl1iLjbfTENBVsb3hMdsvk/eCkub05GnvgjumCa ZNxNv/HHGVSjdn/KxHN1f/pk5UDoQs4098BlQJbRUwXQAPwycDHZavU40Uu20i3dAXFB XX079fMuJyDlOa/T8dP/AmTs+WL68u0ztvm3NmVOIN/HIaarbrlITiN17p5aRW9WcE6r bNfoyulj4rLfMvhqcWR8O66GlTO8BEZsgBxgi43S7wpvOcU9shGKbkVsy5ddONN93Gpk OLuiUtoSL5GPogEo3RLh3hrvb6RSBLW57RcVNoxtnP0+wlhhPPhCn+wjUqaW0EabUNMQ +xkQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t19-v6si20167544pfm.152.2018.10.08.06.59.27; Mon, 08 Oct 2018 06:59:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726442AbeJHVLK (ORCPT + 99 others); Mon, 8 Oct 2018 17:11:10 -0400 Received: from mx2.suse.de ([195.135.220.15]:51672 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726056AbeJHVLK (ORCPT ); Mon, 8 Oct 2018 17:11:10 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id DB827B000; Mon, 8 Oct 2018 13:59:16 +0000 (UTC) Date: Mon, 8 Oct 2018 15:59:16 +0200 From: Petr Mladek 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 Message-ID: <20181008135916.gg4kkmoki5bgtco5@pathway.suse.cz> References: <1538239553-81805-1-git-send-email-zhe.he@windriver.com> <1538239553-81805-4-git-send-email-zhe.he@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1538239553-81805-4-git-send-email-zhe.he@windriver.com> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun 2018-09-30 00:45:53, zhe.he@windriver.com wrote: > From: He Zhe > > Give explicit error for users who want to use larger log buffer. > > Signed-off-by: He Zhe > 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 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 Signed-off-by: He Zhe Signed-off-by: Petr Mladek --- 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