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=-26.3 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_AGENT_GIT,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 1C417C433EF for ; Tue, 7 Sep 2021 14:14:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C2B8961106 for ; Tue, 7 Sep 2021 14:14:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C2B8961106 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 67E4494000C; Tue, 7 Sep 2021 10:14:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 60797940007; Tue, 7 Sep 2021 10:14:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4CF1E94000C; Tue, 7 Sep 2021 10:14:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0190.hostedemail.com [216.40.44.190]) by kanga.kvack.org (Postfix) with ESMTP id 3EE80940007 for ; Tue, 7 Sep 2021 10:14:17 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 06A08181B0493 for ; Tue, 7 Sep 2021 14:14:17 +0000 (UTC) X-FDA: 78560972154.29.FBC5243 Received: from mail-ed1-f73.google.com (mail-ed1-f73.google.com [209.85.208.73]) by imf07.hostedemail.com (Postfix) with ESMTP id B0B1D10000BA for ; Tue, 7 Sep 2021 14:14:16 +0000 (UTC) Received: by mail-ed1-f73.google.com with SMTP id m30-20020a50999e000000b003cdd7680c8cso382224edb.11 for ; Tue, 07 Sep 2021 07:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=7ChlQWANvSBXBNUBCDuMgq5Cekd+HYTjR/ntyIg1Zyg=; b=edoUkiH2Kkf33Hq4VE8PDcQnBfHm5jDj20cp4k+Ev2uzNaB5gKzMC6RyQBjJ/HqWeA 9uhk1YYgKb1sTHBCprikkPstROStRUGJt+ih9Bl0vPYrM4fJzRNU+8YVNEU2c/lesHKs fMkeV5JG0zhQBnMlXbQB78wv25kORlv1naya33fky1/kGMs6AoB4XkDmbXevrTe9zsdB 3gvNw2jML5LfuIwNd8Uu5m9X7nB5Sy0pv7mJcrSPiRtPY0KRkWCf8dbv6a6uZAWAdm7w HYrhWzMSDLxOwDjA2liJXFub2QPHIr2N2pdYf3Z6AsIazDG3kWr4p7d8hMmTeoUc2pBb Q5/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=7ChlQWANvSBXBNUBCDuMgq5Cekd+HYTjR/ntyIg1Zyg=; b=rmGzvdsHBrP0uq6fT8sRPdehKS+Mn1NrU5BcW03yWtfYrgRCnY96CDGB7mnZesuJm0 NUSh/PUcygSmwHPeqH/UiI2jDRQux06Q3ksmAeaWC58mDEP1eBOxhmcAo0AIW/BF8VVS Bfx74lmNBDH/t+xie22m3obusgbPmpyDvjMthc/ugqenWlCDu6DQh80SSFbHwZeAKn6t YFm4VnS60syug/dgsaZMan0KKGwIM/sT/VkpmzgRN9iUp9xE1MSypnPAVbSTq0sv1D4m VflL748JXWpbhQT2gvLTnkUr8MsPtTMb/rizQcB4IhZ7Nlax/UQbWR1w9UXHfc68m4A9 trTw== X-Gm-Message-State: AOAM533sUAe3w0psLPi5QiLPSszw/IeDjPYVHFNXICxDy6GL6tC1h3rb G619SGf4rKfdtM5DsrwKww9b/wsiTw== X-Google-Smtp-Source: ABdhPJyGsdfkionufVLXwZil0TbakqGI5ZpVw9BOrl5sbBB/o1m93aEaygEZ4Rn6IuxIMOU0utYtynfPFQ== X-Received: from elver.muc.corp.google.com ([2a00:79e0:15:13:6800:c1ea:4271:5898]) (user=elver job=sendgmr) by 2002:a05:6402:3107:: with SMTP id dc7mr18886580edb.341.1631024055406; Tue, 07 Sep 2021 07:14:15 -0700 (PDT) Date: Tue, 7 Sep 2021 16:13:07 +0200 In-Reply-To: <20210907141307.1437816-1-elver@google.com> Message-Id: <20210907141307.1437816-7-elver@google.com> Mime-Version: 1.0 References: <20210907141307.1437816-1-elver@google.com> X-Mailer: git-send-email 2.33.0.153.gba50c8fa24-goog Subject: [PATCH 6/6] workqueue, kasan: avoid alloc_pages() when recording stack From: Marco Elver To: elver@google.com Cc: Andrew Morton , Shuah Khan , 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 Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=edoUkiH2; spf=pass (imf07.hostedemail.com: domain of 3t3M3YQUKCIwu1Bu7w44w1u.s421y3AD-220Bqs0.47w@flex--elver.bounces.google.com designates 209.85.208.73 as permitted sender) smtp.mailfrom=3t3M3YQUKCIwu1Bu7w44w1u.s421y3AD-220Bqs0.47w@flex--elver.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: B0B1D10000BA X-Stat-Signature: tgqgic3nqhsr1hij1b4g4hmysmczrsbm X-HE-Tag: 1631024056-626507 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: Shuah Khan reported: | When CONFIG_PROVE_RAW_LOCK_NESTING=y and CONFIG_KASAN are enabled, | kasan_record_aux_stack() runs into "BUG: Invalid wait context" when | it tries to allocate memory attempting to acquire spinlock in page | allocation code while holding workqueue pool raw_spinlock. | | There are several instances of this problem when block layer tries | to __queue_work(). Call trace from one of these instances is below: | | kblockd_mod_delayed_work_on() | mod_delayed_work_on() | __queue_delayed_work() | __queue_work() (rcu_read_lock, raw_spin_lock pool->lock held) | insert_work() | kasan_record_aux_stack() | kasan_save_stack() | stack_depot_save() | alloc_pages() | __alloc_pages() | get_page_from_freelist() | rm_queue() | rm_queue_pcplist() | local_lock_irqsave(&pagesets.lock, flags); | [ BUG: Invalid wait context triggered ] The default kasan_record_aux_stack() calls stack_depot_save() with GFP_NOWAIT, which in turn can then call alloc_pages(GFP_NOWAIT, ...). In general, however, it is not even possible to use either GFP_ATOMIC nor GFP_NOWAIT in certain non-preemptive contexts, including raw_spin_locks (see gfp.h and ab00db216c9c7). Fix it by instructing stackdepot to not expand stack storage via alloc_pages() in case it runs out by using kasan_record_aux_stack_noalloc(). While there is an increased risk of failing to insert the stack trace, this is typically unlikely, especially if the same insertion had already succeeded previously (stack depot hit). For frequent calls from the same location, it therefore becomes extremely unlikely that kasan_record_aux_stack_noalloc() fails. Link: https://lkml.kernel.org/r/20210902200134.25603-1-skhan@linuxfoundation.org Reported-by: Shuah Khan Signed-off-by: Marco Elver --- kernel/workqueue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 50142fc08902..0681774e6908 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -1329,7 +1329,7 @@ static void insert_work(struct pool_workqueue *pwq, struct work_struct *work, struct worker_pool *pool = pwq->pool; /* record the work call stack in order to print it in KASAN reports */ - kasan_record_aux_stack(work); + kasan_record_aux_stack_noalloc(work); /* we own @work, set data and link */ set_work_pwq(work, pwq, extra_flags); -- 2.33.0.153.gba50c8fa24-goog