From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A34C4C54FCB for ; Fri, 24 Apr 2020 14:00:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7E04E20776 for ; Fri, 24 Apr 2020 14:00:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727919AbgDXOAp (ORCPT ); Fri, 24 Apr 2020 10:00:45 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:63065 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726301AbgDXOAp (ORCPT ); Fri, 24 Apr 2020 10:00:45 -0400 Received: from fsav101.sakura.ne.jp (fsav101.sakura.ne.jp [27.133.134.228]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 03OE04nq053316; Fri, 24 Apr 2020 23:00:04 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav101.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav101.sakura.ne.jp); Fri, 24 Apr 2020 23:00:04 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav101.sakura.ne.jp) Received: from [192.168.1.9] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 03OE04kZ053313 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Apr 2020 23:00:04 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: [PATCH] printk: Add loglevel for "do not print to consoles". To: Steven Rostedt Cc: Petr Mladek , Sergey Senozhatsky , linux-kernel@vger.kernel.org, Dmitry Safonov , Michal Hocko , Yafang Shao References: <20200424024239.63607-1-penguin-kernel@I-love.SAKURA.ne.jp> <20200424092816.62a61b1d@gandalf.local.home> From: Tetsuo Handa Message-ID: <579fbe97-9aae-2b67-03ff-01291b9cbb7d@i-love.sakura.ne.jp> Date: Fri, 24 Apr 2020 23:00:01 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200424092816.62a61b1d@gandalf.local.home> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/04/24 22:28, Steven Rostedt wrote: > What I would suggest doing is create your own buffer to store the output. > Then use the seq_buf() operations and such to print to that buffer, and > then be able to read that output from something like a debug filesystem, or > some user space daemon that will write to syslog. Since KERN_NO_CONSOLES is for -ENOMEM situations (GFP_KERNEL allocation which can sleep needs to invoke the OOM killer, or GFP_ATOMIC allocation which cannot sleep has failed), we can't create buffer on demand. For process context, it would be possible to create buffer upon fork() time. But for atomic context, it is so difficult to create buffer on demand. We could allocate shared buffer like logbuf but it means that we have to replicate what printk() is doing (too much code), for when atomic memory allocation happens resembles when printk() is called. Borrowing printk()'s logbuf is simpler.