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;
Date:   Tue, 18 Sep 2018 22:43:12 -0400
From:   Steven Rostedt <rostedt@goodmis.org>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc:     He Zhe <zhe.he@windriver.com>, pmladek@suse.com,
        sergey.senozhatsky@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len
 to command line
Message-ID: <20180918224312.6e9aef50@vmware.local.home>
In-Reply-To: <20180919023932.GA14090@jagdpanzerIV>
References: <1537291068-443145-1-git-send-email-zhe.he@windriver.com>
        <20180919015030.GA423@jagdpanzerIV>
        <6c354803-5341-7237-9ee3-7882252c7483@windriver.com>
        <20180919023932.GA14090@jagdpanzerIV>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, 19 Sep 2018 11:39:32 +0900
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:

> On (09/19/18 10:27), He Zhe wrote:
> > On 2018年09月19日 09:50, Sergey Senozhatsky wrote:  
> > > On (09/19/18 01:17), zhe.he@windriver.com wrote:  
> > >> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned 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);
> > >> +	unsigned size;  
> > > 	unsigned int size;  
> > 
> > This is in v1 but then Steven suggested that it should be split out
> > and only keep the pure fix part here.  
> 
> Ah, I see.
> 
> Hmm... memparse() returns u64 value. A user *probably* can ask the kernel
> to allocate log_buf larger than 'unsigned int'.
> 
> So may be I'd do two fixes here:
> 
>  First  - switch to u64 size.
>  Second - check for NULL str.
> 
> 
> Steven, Petr, what do you think?
> 

I think I would switch it around. Check for NULL first, and then switch
to u64. It was always an int, do we need to backport converting it to
u64 to stable? The NULL check is a definite, the overflow of int
shouldn't crash anything.

-- Steve