Received: by 2002:a5d:925a:0:0:0:0:0 with SMTP id e26csp401646iol; Thu, 9 Jun 2022 06:13:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxkYh+c6LW1ePTe9TL7CiEhIbOhttW9SV9qniUqTmD0+Iekkc/TPOm0O51btd/0Nx9w/3zx X-Received: by 2002:a17:906:54c3:b0:6ef:d07b:c8ec with SMTP id c3-20020a17090654c300b006efd07bc8ecmr35798039ejp.687.1654780421115; Thu, 09 Jun 2022 06:13:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654780421; cv=none; d=google.com; s=arc-20160816; b=Ec2+Lv70Fb2ewBUQHINeF/+1TKEBrXXevMqivXuCmkkUIRdNhOgvLLFVGucsU6VO51 7OKUmWfibusDfCsS9GgLjzlEurkg5T+41+qIK9yPiiya8tiDRuptl5wRS8A6mxJDjzXl aXXqaaVlXM+7JplhN7qlpebFDrhK41FNUXRuJ43Wli7zNLaIyka3NZV/80RxqtyACsWW 3tgxGxVnq+Y5y2zOoPlvw3Jn0WUyQWV6HitY2MOAiTu+WKmL3PpqjIV9RNLkRE6nCB37 ybOrfZChCLR/7h5GV4+VZ8oKu3mhcjPYmqBE7s7m3qE8M2aSn9WPwxWQ066jW0Yiu98R xY0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=SfBdadjjVbuYsWcHjyT2JNkeKnRXZofpQUc3M0v3lw8=; b=uG9N3JIzcnMWCGL3Yr9lel94caMoWzUzcFrcQlfksSOenjIdl0NHHgrdDeUozYxVWo Gln2806Y6Xs5bv6JKgP1+BXZPoYwnJXAR/QO0M9WJFlINc4mfhEFDdGNHpZCgJdGxWee J2ct4xc1bbgRV7D/CLddi/nFOfKo/N3cXGCSfAUjoxCibajwFFmfHO/lXOy70nVFmHBp TNxMmvousbhRbcWCM1JPKILtX4/DjQuL9WFcuelIUMBg7KAtfnX/UGyhS97l+la812ht WCtaJEoWPdN/xbzZpyZeHIo72/6bTaNK7sJyqYoA/y0AO5mkMCm8SSCXyhJ0bIwkkAcm oqmg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=ZuexHRJp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sd22-20020a1709076e1600b00702d8bd9e13si2836901ejc.707.2022.06.09.06.13.09; Thu, 09 Jun 2022 06:13:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=ZuexHRJp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235951AbiFIMcS (ORCPT + 99 others); Thu, 9 Jun 2022 08:32:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47004 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237961AbiFIMcP (ORCPT ); Thu, 9 Jun 2022 08:32:15 -0400 Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7522118353 for ; Thu, 9 Jun 2022 05:32:13 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id h23so37753660lfe.4 for ; Thu, 09 Jun 2022 05:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SfBdadjjVbuYsWcHjyT2JNkeKnRXZofpQUc3M0v3lw8=; b=ZuexHRJpNkArhkzlyVFzZzfvSGVG0EYbj1SnK7hExFfijK7WjsRYWBLE0IAgfsl2Zi MEyYD78r42eLMgaGkHPJR1S3gTnNwQnEllIN+QBILQnNTymZq4f19Yu/6jG5M503bWVv sTnn/1fbYfOfY6pb0CbXuakmf+f9jM1TKXottjCpAfvvenicMckun+zADDhluMOtEFEr Fltda09pvIbbAqK5WXQ/PojELjI4dNLYnujpwmEs+PosBQICQSiY48ZEGW61ag+09nDR naerd/Vk9Iwjla68zxr0uqMt7jTerwywgXFZ3UjNXRbXyEQGZgLfPS9674SbORQU4h6m PWww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SfBdadjjVbuYsWcHjyT2JNkeKnRXZofpQUc3M0v3lw8=; b=Il26Rr0jriFE7IGnTdmZvmvlbRQXwNRkAYyT2LOu/oGOgYvkWQ4iz+FQR1i2mq0aFw 5C7VQ0eq/m0TjJds5ATYAYEOgVS3ZMs9/u7Rj/DKYLxjb7hTl1sRMxINQHyzjHSt7ynq IzFs/i8uPp8iWWxPFqw0/ZDcBDIthQnqToU1VDQLDFPqrwnfiLOHsTKPQ82ip5Cj+wMY Nz5hq9nWCcbuhkvfFRuSDCS8MRL26XkRAtMr26sGEiCjdxaQOwUo95iuvzJdbwf6a9ia p9oWuEhCjM9KXU20e47b3ofJx2qFpetKpw2MerxnRHEGif+1VrC1/NTUscmf0oI2xsIt dKEw== X-Gm-Message-State: AOAM532bnxEMcPtNhtmW5efJaNS2iPFaNPTnxv0b1Up5yqLRVyfrR5cl +23Ji83RZwQ9HmZb1fY5rKO8/wSwxA6SZTV1T4/LSA== X-Received: by 2002:a05:6512:1588:b0:477:a556:4ab2 with SMTP id bp8-20020a056512158800b00477a5564ab2mr24638097lfb.376.1654777931483; Thu, 09 Jun 2022 05:32:11 -0700 (PDT) MIME-Version: 1.0 References: <87fslyv6y3.fsf@jogness.linutronix.de> <51dfc4a0-f6cf-092f-109f-a04eeb240655@samsung.com> <87k0b6blz2.fsf@jogness.linutronix.de> <32bba8f8-dec7-78aa-f2e5-f62928412eda@samsung.com> <87y1zkkrjy.fsf@jogness.linutronix.de> <87fske3wzw.fsf@jogness.linutronix.de> In-Reply-To: From: Dmitry Vyukov Date: Thu, 9 Jun 2022 14:32:00 +0200 Message-ID: Subject: Re: [PATCH printk v5 1/1] printk: extend console_lock for per-console locking To: "Jason A. Donenfeld" Cc: John Ogness , Geert Uytterhoeven , Marek Szyprowski , Petr Mladek , Sergey Senozhatsky , Steven Rostedt , Thomas Gleixner , Linux Kernel Mailing List , Greg Kroah-Hartman , "open list:ARM/Amlogic Meson..." , "Theodore Ts'o" , Alexander Potapenko , Marco Elver , kasan-dev@googlegroups.com, bigeasy@linutronix.de Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 9 Jun 2022 at 14:27, Jason A. Donenfeld wrote: > > Hi Dmitry, > > On Thu, Jun 09, 2022 at 02:18:19PM +0200, Dmitry Vyukov wrote: > > > AFAIK, CONFIG_PROVE_RAW_LOCK_NESTING is useful for teasing out cases > > > where RT's raw spinlocks will nest wrong with RT's sleeping spinlocks. > > > But nobody who wants an RT kernel will be using KFENCE. So this seems > > > like a non-issue? Maybe just add a `depends on !KFENCE` to > > > PROVE_RAW_LOCK_NESTING? > > > > Don't know if there are other good solutions (of similar simplicity). > > Fortunately, I found one that solves things without needing to > compromise on anything: > https://lore.kernel.org/lkml/20220609121709.12939-1-Jason@zx2c4.com/ Cool! Thanks! > > Btw, should this new CONFIG_PROVE_RAW_LOCK_NESTING be generally > > enabled on testing systems? We don't have it enabled on syzbot. > > Last time I spoke with RT people about this, the goal was eventually to > *always* enable it when lock proving is enabled, but there are too many > bugs and cases now to do that, so it's an opt-in. I might be > misremembering, though, so CC'ing Sebastian in case he wants to chime > in. OK, we will wait then. Little point in doubling the number of reports for known issues.