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=-23.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=ham 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 80252C433F5 for ; Mon, 13 Sep 2021 06:01:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0262760ED7 for ; Mon, 13 Sep 2021 06:01:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0262760ED7 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 9CEFA6B0071; Mon, 13 Sep 2021 02:01:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 97E0D6B0072; Mon, 13 Sep 2021 02:01:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 86DE56B0073; Mon, 13 Sep 2021 02:01:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0089.hostedemail.com [216.40.44.89]) by kanga.kvack.org (Postfix) with ESMTP id 77C2F6B0071 for ; Mon, 13 Sep 2021 02:01:37 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 2B8FD274B4 for ; Mon, 13 Sep 2021 06:01:37 +0000 (UTC) X-FDA: 78581503434.01.8CF5A63 Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) by imf04.hostedemail.com (Postfix) with ESMTP id E38C550000BD for ; Mon, 13 Sep 2021 06:01:36 +0000 (UTC) Received: by mail-oi1-f176.google.com with SMTP id c79so12644365oib.11 for ; Sun, 12 Sep 2021 23:01:36 -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=jdwXw6pKQ+eOL7alcxynWehyVWgh/32RHEhD8lJnqhE=; b=FBZ+QyXWzzvyrXbXx8dunA0rlJgVVLlx1xbZ3blIWhHw/bXZ3Jg7jH0+P6xUgYRtC9 6dT6J4+Li3oGBbhVAQGdzW7YWyg2tM9PIoJRIW6BJ/0Zus/TeoBRKw90P5FTgR0d8b6s iBBPwjyj3SJfuu3fAMplt0edGhhjb+hSJyavqQeUgUYXCQPMuQplL2yeLijHwRb0R8ID ZhDmjQoUeycWH7tpD4newTt/r9NSQ9eZ4DgntF5zGRQEOcZRici5wZjrYMgKztElPf67 oTIE2Je7DydJHu9kLAXD0Na/aNj+rPFCFY8z1MbKsWG4bJt2IvGci6uyKqkqvIN2INg5 1oZg== 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=jdwXw6pKQ+eOL7alcxynWehyVWgh/32RHEhD8lJnqhE=; b=5038Ysyt9qwMhaT+fyKlCPBDKiVmTM2FPuzOJacesqHrbeLRs62lLDc90Ux49bcW1R gpcPWcikq9Yn33eW6Jvx7velMuTyyaweJ6F4vqvjrsqhS1+pl0DCTBSl+lKQwcFNxkxx ZJzwTFiHWYsLbZOhglWZLomK+JJmI5jLnHewLzxW5Sb+FXlv0tqDV4X7SYEt7hWssNQ1 nUc4XFrSR/Io0qMqJXxLgyQjYwdyh8DhqQSijk9ykKU5TiM1doe+WJrQtCRzPvWi5i/K pflGjWbPQBInOJrU2kxfih7A4qNkHvf7y0qypuXymwduZlrCSGeYUN2JuV2N49Tk3FgL o4WQ== X-Gm-Message-State: AOAM530eIJEMVQSw37jDnJ+dPMmJtUQyNoD0VOjme+ZlTztxxVU9Eiby HWxy2mdpXstqVmbG1uLSa3HaYvSrml/0KDzU0eMNOA== X-Google-Smtp-Source: ABdhPJwLVPvofjlvZMRAK2IxjL00Q1B1EyeeOwdxBZGMGU9GZFSSkM2WueJgbZCEVgp0ggIYgRR7JcTuasdNPAtKmJQ= X-Received: by 2002:a05:6808:21a5:: with SMTP id be37mr6405238oib.172.1631512896132; Sun, 12 Sep 2021 23:01:36 -0700 (PDT) MIME-Version: 1.0 References: <20210907141307.1437816-1-elver@google.com> <69f98dbd-e754-c34a-72cf-a62c858bcd2f@linuxfoundation.org> <1b1569ac-1144-4f9c-6938-b9d79c6743de@suse.cz> <20210910152819.ir5b2yijkqly3o6l@linutronix.de> In-Reply-To: <20210910152819.ir5b2yijkqly3o6l@linutronix.de> From: Marco Elver Date: Mon, 13 Sep 2021 08:00:00 +0200 Message-ID: Subject: Re: [PATCH 0/6] stackdepot, kasan, workqueue: Avoid expanding stackdepot slabs when holding raw_spin_lock To: Sebastian Andrzej Siewior Cc: Vlastimil Babka , Shuah Khan , Andrew Morton , Tejun Heo , Lai Jiangshan , Andrey Konovalov , Walter Wu , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Vijayanand Jitta , Vinayak Menon , "Gustavo A. R. Silva" , kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Aleksandr Nogikh , Taras Madan , Thomas Gleixner , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: E38C550000BD X-Stat-Signature: ex8k9a8nymua1s7f1sm3jmz1r3uy5gpo Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=FBZ+QyXW; spf=pass (imf04.hostedemail.com: domain of elver@google.com designates 209.85.167.176 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1631512896-233854 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 Fri, 10 Sept 2021 at 17:28, Sebastian Andrzej Siewior wrote: > On 2021-09-10 12:50:51 [+0200], Vlastimil Babka wrote: > > > Thank you. Tested all the 6 patches in this series on Linux 5.14. This problem > > > exists in 5.13 and needs to be marked for both 5.14 and 5.13 stable releases. > > > > I think if this problem manifests only with CONFIG_PROVE_RAW_LOCK_NESTING > > then it shouldn't be backported to stable. CONFIG_PROVE_RAW_LOCK_NESTING is > > an experimental/development option to earlier discover what will collide > > with RT lock semantics, without needing the full RT tree. > > Thus, good to fix going forward, but not necessary to stable backport. > > Acked-by: Sebastian Andrzej Siewior > for the series. Thank you. Thank you. I'll send v2 with Acks/Tested-by added and the comment addition you suggested. > As for the backport I agree here with Vlastimil. > > I pulled it into my RT tree for some testing and it looked good. I had > to > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -3030,7 +3030,7 @@ __call_rcu(struct rcu_head *head, rcu_callback_t func) > head->func = func; > head->next = NULL; > local_irq_save(flags); > - kasan_record_aux_stack(head); > + kasan_record_aux_stack_noalloc(head); > rdp = this_cpu_ptr(&rcu_data); > > /* Add the callback to our list. */ > > We could move kasan_record_aux_stack() before that local_irq_save() but > then call_rcu() can be called preempt-disabled section so we would have > the same problem. > > The second warning came from kasan_quarantine_remove_cache(). At the end > per_cpu_remove_cache() -> qlist_free_all() will free memory with > disabled interrupts (due to that smp-function call). > Moving it to kworker would solve the problem. I don't mind keeping that > smp_function call assuming that it is all debug-code and it increases > overall latency anyway. But then could we maybe move all those objects > to a single list which freed after on_each_cpu()? The quarantine is per-CPU, and I think what you suggest would fundamentally change its design. If you have something that works on RT without a fundamental change would be ideal (it is all debug code and not used on non-KASAN kernels). > Otherwise I haven't seen any new warnings showing up with KASAN enabled. > > Sebastian