Received: by 2002:a4a:301c:0:0:0:0:0 with SMTP id q28-v6csp833440oof; Tue, 25 Sep 2018 05:23:33 -0700 (PDT) X-Google-Smtp-Source: ACcGV625B9p2DPupIAz1GRe86pzAzl6qPgB1XFRGk1kg9IlzgohJPGbTM8AvnxK5+0U4pc/WEW5D X-Received: by 2002:a17:902:2ac3:: with SMTP id j61-v6mr976513plb.172.1537878213342; Tue, 25 Sep 2018 05:23:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537878213; cv=none; d=google.com; s=arc-20160816; b=SkVnwia0MnCklsd4UCYg7h1E1F52O8URc5DHqWshSfVZ54CKyASymZFvsPoDbLg0pz WHGVmJJ/+1MXnXtxi8VX0VLi+LjKaZqeA/4+WZjcHOMkuCJxjEh0iReVUQMdL/ogpCXV pOdNZ5mlze/lD6n7APOdRIQ+Q4CYRkaJEgNyd5rMOPFH5TND9+nqA4ZYu7cl6UOWP5EI 815TzcywU2dXpoFiA5YZjUm4kMrqAfWVXdTyrwjH6RKv1mYJoFhCuoZMIM4r+x1CqJT5 v+tKX9ziQhQt0xaQF/TPWU+xfnr7ZeRPLL/d07rp7FH7ZDU+2evMS2KK5P8Tg5GaKbY0 qvmg== 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=HVQgkPTF+9QVZFbRlwyQB8vct5bySp+Y90kHkALk/74=; b=YHf+1F+GFfo75vtJDg87EK0k/JwURMGW7s1FSfftADt+Zy1uGdF5CVhJqr0pJTq4ET t2yAtVmstswLLtCzrub+eFyHqNWyPgJ/smoD+fmoN6VCMFvLkLbTy4H7XZlzl6yAhaaQ 3BK+ScEAULgXkSv6y/0108Jc5jc70dO/Vvww95CPZwUgbefAYLxPm+JzzuTX/4mVVwHS M+4XoyDra8WQvbLPH09XRL7LZ4KkNnYnUccL7/zpc0JVzpfL3v+xQgpJXwfQDlDm62uL OzPyHorZJwyI25+m5aARGHbPpd81MjL8wss206FN4D4i/dkxooUsD1wal5KHyQHXSjvq gU/A== 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 v6-v6si2222723plp.434.2018.09.25.05.23.18; Tue, 25 Sep 2018 05:23:33 -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 S1728878AbeIYSaV (ORCPT + 99 others); Tue, 25 Sep 2018 14:30:21 -0400 Received: from mx2.suse.de ([195.135.220.15]:60182 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728468AbeIYSaV (ORCPT ); Tue, 25 Sep 2018 14:30:21 -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 BF94CAEAE; Tue, 25 Sep 2018 12:23:01 +0000 (UTC) Date: Tue, 25 Sep 2018 14:23:00 +0200 From: Petr Mladek To: Sergey Senozhatsky Cc: Steven Rostedt , He Zhe , Sergey Senozhatsky , 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: <20180925122300.qq5w4skwmxbzi6sy@pathway.suse.cz> References: <1537291068-443145-1-git-send-email-zhe.he@windriver.com> <20180919015030.GA423@jagdpanzerIV> <6c354803-5341-7237-9ee3-7882252c7483@windriver.com> <20180919023932.GA14090@jagdpanzerIV> <20180918224312.6e9aef50@vmware.local.home> <1545bc85-b64a-4b45-d40f-79567ac621dc@windriver.com> <20180920123056.27b2cf18@gandalf.local.home> <20180921073753.mqayzofcofpmhiyu@pathway.suse.cz> <20180925120135.GB523@tigerII.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180925120135.GB523@tigerII.localdomain> 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 Tue 2018-09-25 21:01:35, Sergey Senozhatsky wrote: > On (09/21/18 09:37), Petr Mladek wrote: > > > > I would personally keep the size as unsigned int. IMHO, a support > > for a log buffer bigger than 4GB is not worth the complexity. > > > > ftrace dumps are bothering me. > > Steven Rostedt wrote [0]: > > > > Especially when I have a machine with 240 CPUs. But it also has a ton of > > RAM, I could easily do log_buf_len=32G > > > > The systems are getting bigger, so log_buf_len=UINT_MAX+ might become > a norm at some point. Thanks for pointing this out. Well, it seems that the change would require a new syscall to pass the buffer size as long. We need to be sure that people would use this in the real life. This thread suggested this change to avoid a checkpatch warning. The 32GB was mentioned as an example one year ego. This is not enough for a new syscall from my point of view. Best Regards, Petr