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=-8.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 0FAD4CA9EB6 for ; Wed, 23 Oct 2019 17:57:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BCF332173B for ; Wed, 23 Oct 2019 17:57:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Q2XMdPOP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BCF332173B Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 72FD96B0006; Wed, 23 Oct 2019 13:57:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E0B76B0007; Wed, 23 Oct 2019 13:57:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 61D666B0008; Wed, 23 Oct 2019 13:57:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0160.hostedemail.com [216.40.44.160]) by kanga.kvack.org (Postfix) with ESMTP id 3F8C86B0006 for ; Wed, 23 Oct 2019 13:57:53 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id D8105181AC9CC for ; Wed, 23 Oct 2019 17:57:52 +0000 (UTC) X-FDA: 76075807584.21.note46_44be7642eec5a X-HE-Tag: note46_44be7642eec5a X-Filterd-Recvd-Size: 5838 Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Wed, 23 Oct 2019 17:57:52 +0000 (UTC) Received: by mail-wm1-f66.google.com with SMTP id q70so15085661wme.1 for ; Wed, 23 Oct 2019 10:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+v9mCVaUiy001r1GMvxHAg5hCbJzng7FpxP1rXl9vrA=; b=Q2XMdPOP9HNgeArvDvGq70yDeVj6TGcO98jW+LDtGsckh2s8EpCSslFCuIXYiKkxZL XxXTsBX5v69+q/Wd2w6a4tkEHUV2P6+/Tb4e0wvpRXmaphkuGkqoWzV/T7tnjw2qSjpb pfZNQkySm7G9btY4u1QRFTnZv3AcNZdXzlycNBF1Y53Rib9K/EQGpl5Ww/fxVDYtt6kl NEGhgeP39+kzBXGBQBzr8JIKn1fGyloEW6ZANrlRW+8XHnquBIBSF8bJuRzVQGc5fLk8 4uwxq3eqaxttPZMVyR/Yew/g4Ad5EQGZhox/loIio4Z0GPJL+o1B9jtmurrLl6Ontdoe uKMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+v9mCVaUiy001r1GMvxHAg5hCbJzng7FpxP1rXl9vrA=; b=FpS6xLbwaFJHINy9SjujdDaTfHfNWLZVDh+HOzYh6hM3Zy5EnOpvjj0BsVwzMzUjme dnAkv9f/OVYIKMDO5vtuXq/JaiD+7HUK57eNRLSKv92kDutL+hPdSbdbCq7f6iJZ2sCc KdVz/gaPw8wVdq/i3Q8gLvIghfwLPDyppT5IXC/S6ad/a8nB07BO/wVhKFSVuB0i9cGL WLkLf1eimtPoWF6KrCOD9nNl5M4Jy01lOWTQFHjwcH/r9DD7qIsUNU6IV96iPLH0LwCO o94he3cQ8w2roQbnfPxV3rqQ7VcMcVj64CEhMmBXi4o/wUlGIit/zWm1wUGiULCqtu+w tEHg== X-Gm-Message-State: APjAAAXtsNR6CRl9MA0c2kCn9Alh+zQMChqkg6zf+xTZBgWvZi2Cj80z jmofut3VsB/rpRRG8XvaAJJNmQ+0Jszlrhx57wXkNg== X-Google-Smtp-Source: APXvYqxFa1uLwgFzPezO/79oY9DeF4LtSJrewJb/XMKu5uxgpW5yLV+u2YP9Gw6BndIll/2AzCsoS4N91YZuEOeoTf0= X-Received: by 2002:a05:600c:2317:: with SMTP id 23mr1038569wmo.140.1571853470650; Wed, 23 Oct 2019 10:57:50 -0700 (PDT) MIME-Version: 1.0 References: <20191018094304.37056-1-glider@google.com> <20191018094304.37056-6-glider@google.com> <20191021090925.3dcqukovauqsyw5w@pathway.suse.cz> In-Reply-To: <20191021090925.3dcqukovauqsyw5w@pathway.suse.cz> From: Alexander Potapenko Date: Wed, 23 Oct 2019 19:57:39 +0200 Message-ID: Subject: Re: [PATCH RFC v1 05/26] printk_safe: externalize printk_context To: Petr Mladek Cc: Vegard Nossum , Sergey Senozhatsky , Steven Rostedt , Dmitry Vyukov , Linux Memory Management List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, Oct 21, 2019 at 11:09 AM Petr Mladek wrote: > > On Fri 2019-10-18 11:42:43, glider@google.com wrote: > > Petr Mladek suggested we use > > this_cpu_read(printk_context) & PRINTK_SAFE_CONTEXT_MASK > > instead of checking the spinlock status in kmsan_pr_err() > > I would like to understand why the check is needed. > > My guess is that it prevents a infinite recursion. > Is this the case? It might be possible to debug this using > trace_printk(). This indeed used to prevent infinite recursion, however looks like the check isn't needed anymore. When I remove it, KMSAN doesn't hang, probably because printk is doing a better job at deadlock prevention. What I'm seeing now is that e.g. in the following case: ptr =3D 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/0x19= 00 ... [ 59.062961][ C0] BUG: KMSAN: uninit-value in format_decode+0x17f/0x19= 00 ... [ 59.063338][ C0] Lost 6207 message(s)! So it turns out we'd better disable reporting under logbuf_lock, otherwise these lost messages will confuse the developers. Because the first pr_info() isn't called by KMSAN itself, the tool still needs a way to know it's running inside printk. > It is important. If it is the recursion then there are > two possibilities how to prevent it. Either prevent > calling the recursive printk(). Or prevent calling > the memory checker recursive. I am not sure what makes > more sense. > > Is printk() the only piece of code where you need to avoid > recursion? I wonder how it is prevented in the other cases. > > > This appears to be less intrusive, although we'll need to declare > > printk_context in some printk header. > > It is easier than the original approach. But the main motivation > is that it is more reliable. The spinlock is a global lock. > But it seems that it is enough to check the state of the local > CPU. > > Finally, could you please CC me to the patch(es) that are using > this variable? I would actually prefer to be in CC of entire > patchsets so that I see the full context. > > Best Regards, > Petr --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg