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,URIBL_BLOCKED,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 0C9CCCA9EAE for ; Tue, 29 Oct 2019 12:02:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AFAC9208E3 for ; Tue, 29 Oct 2019 12:02:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AFAC9208E3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 17F196B0005; Tue, 29 Oct 2019 08:02:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 12EE86B0006; Tue, 29 Oct 2019 08:02:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 06CBE6B0007; Tue, 29 Oct 2019 08:02:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0182.hostedemail.com [216.40.44.182]) by kanga.kvack.org (Postfix) with ESMTP id D969D6B0005 for ; Tue, 29 Oct 2019 08:02:38 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 7A5E775B3 for ; Tue, 29 Oct 2019 12:02:38 +0000 (UTC) X-FDA: 76096685196.14.judge82_5131fd918c718 X-HE-Tag: judge82_5131fd918c718 X-Filterd-Recvd-Size: 4276 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Tue, 29 Oct 2019 12:02:37 +0000 (UTC) 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 2171AAFBC; Tue, 29 Oct 2019 12:02:36 +0000 (UTC) Date: Tue, 29 Oct 2019 13:02:35 +0100 From: Petr Mladek To: Alexander Potapenko Cc: Vegard Nossum , Sergey Senozhatsky , Steven Rostedt , Dmitry Vyukov , Linux Memory Management List Subject: Re: [PATCH RFC v1 05/26] printk_safe: externalize printk_context Message-ID: <20191029120235.uncxoraf4ex2haut@pathway.suse.cz> References:<20191018094304.37056-1-glider@google.com> <20191018094304.37056-6-glider@google.com> <20191021090925.3dcqukovauqsyw5w@pathway.suse.cz> <20191024124634.hzsn74l7q4nl4mti@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170912 (1.9.0) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon 2019-10-28 14:09:29, Alexander Potapenko wrote: > On Thu, Oct 24, 2019 at 2:46 PM Petr Mladek wrote: > > On Wed 2019-10-23 19:57:39, Alexander Potapenko wrote: > > > What I'm seeing now is that e.g. in the following case: > > > ptr = kmalloc(sizeof(int), GFP_KERNEL); > > > if (ptr) > > > pr_info("true\n"); > > > else > > > pr_info("false\n"); > > > > > > KMSAN detects errors within pr_info(), namely in vprintk_store(). > > > If I understand correctly, printing from that point causes printk to > > > use the per-cpu buffer, which is flushed once we're done with the > > > original printing: > > > > > > [ 58.984971][ T8390] BUG: KMSAN: uninit-value in > > > kmsan_handle_vprintk+0xa0/0xf0 > > > ... > > > [ 59.061976][ C0] BUG: KMSAN: uninit-value in vsnprintf+0x3276/0x32b0 > > > ... > > > [ 59.062457][ C0] BUG: KMSAN: uninit-value in format_decode+0x17f/0x1900 > > > ... > > > [ 59.062961][ C0] BUG: KMSAN: uninit-value in format_decode+0x17f/0x1900 > > > > Please, do you have an explanation where the uninitialized values come > > from? Is it a false positive? Or is there really a bug how the > > printk() parameters are passed? > I believe these are true bugs. > The problem is, when we pass an uninitialized argument into printk(), > KMSAN will report an error every time this uninitialized argument is > used. I see, thanks for explanation. > E.g. for an uninitialized format string there'll be at least > strlen(fmt) reports in format_decode(), followed by several reports in > vsnprintf(). > Although these reports seem to be real, printing only the first of > them should be more than enough. Isn't this a generic problem? I mean that uninitialized values can be passed and used also in many other locations. printk() is special because this problem causes infinite loop. But it would make sense to report also any other problematic value only once. > In the future we'll actually want KMSAN to check every printk() > argument (which will require parsing the format string to figure out > the arguments' lengths), but disable reports within printk. What is the motivation for this, please? It looks to me that you want to do very paranoid checks of variables passed to printk()? Do you want to prevent printk() crashes? Or do you want to make sure that printk() produces correct values? >From my POV, printk() is debugging tool. It is used to show values that people are interested in. On one hand, it might make sense to warn people that a particular value was not initalized. On the other hand, printk() is not important for the kernel behavior. It just reads values and does not affect any behavior. I would like to understand how many printk-related code is worth the effort. Best Regards, Petr