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.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_AGENT_GIT,USER_IN_DEF_DKIM_WL autolearn=unavailable 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 BB087C433F5 for ; Mon, 13 Sep 2021 11:26:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A614160FE6 for ; Mon, 13 Sep 2021 11:26:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239641AbhIML2H (ORCPT ); Mon, 13 Sep 2021 07:28:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239584AbhIML17 (ORCPT ); Mon, 13 Sep 2021 07:27:59 -0400 Received: from mail-wr1-x44a.google.com (mail-wr1-x44a.google.com [IPv6:2a00:1450:4864:20::44a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 254D0C061762 for ; Mon, 13 Sep 2021 04:26:43 -0700 (PDT) Received: by mail-wr1-x44a.google.com with SMTP id r9-20020a5d4989000000b0015d0fbb8823so2360174wrq.18 for ; Mon, 13 Sep 2021 04:26:43 -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=uXbisNK0hzVjo0x7v5RilsBzlcwLLC23aSoidmJI5Q0=; b=H9qgnMTa7AwCb5iArY+iTSmQ//hjkA1MCsuLuaE4/RUP/gDWt1slOPQx83Is1+UEkZ 7ldVIUBdbaEIP8vDVZbuoQ50dIniyyxtoZvPOB7cxVpBscdCyAJjLOWmnqdQeR+x+CNV R59jlsb5GGt4EU0SDMVHt3JiOYWGuHTSUdLo8AkvkHKv5yH8yYTSjCJrl4UZcNae/xqq wktQQsT9+pUVwO6scHnOqIkHX9607WZlLiri4nKPcHURD/uZZHKIepPX2DvcPENMqu+3 F0+uiIXW/gXBoLzzXUe4/bIjb/o7pcxzwMA2jaCf0hlT4hzHNQQxAMwxo+HxFlz61eyy yNow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=uXbisNK0hzVjo0x7v5RilsBzlcwLLC23aSoidmJI5Q0=; b=i6DzX9Hx9WtLwvYnDIG7imoYweu4ikxkizn+Kj/BMNsLSVjMSI0VBUlnbc1upDHq9O 4ig37y0sCZql6DTx8Tb1m140mGhZV5DZVwcLymklAgAIdGznPNsHGATzgBiXJoUhDim2 eQsHmcGCLY0VkfJkgT+wRkRUNXyPoXaaLdQ9AvKpd977isovOplYgtXYUflO+QM8gT// u+n0OAlegEUPMcsBffyRX3tLhEvYUOvneLSRCjMTXQhHunBacyCQhc4RZML1rSR64Xx6 dkaDA/d+dB70/owe8+6jcgoWYC96kdzAlzdvL7Pl1wgdjjPBBzDyWp8UZJW0Y1V4NQFS zIQw== X-Gm-Message-State: AOAM531gDfzcQIWsPDVU4vna7W3nYB4UgqDRtP9fNNQBplSKLKMPAyto NmpfMz785Tto7qGT+1zpor774T4sXQ== X-Google-Smtp-Source: ABdhPJwrHYb2pQNJIWj/O8r94l5tGwmsJgjQ5oX69os6T91IbgkHBm7FGNsYkspC/6g0HsRIyu30TJmAcA== X-Received: from elver.muc.corp.google.com ([2a00:79e0:15:13:1f19:d46:38c8:7e48]) (user=elver job=sendgmr) by 2002:a05:600c:245:: with SMTP id 5mr9896478wmj.53.1631532401563; Mon, 13 Sep 2021 04:26:41 -0700 (PDT) Date: Mon, 13 Sep 2021 13:26:09 +0200 In-Reply-To: <20210913112609.2651084-1-elver@google.com> Message-Id: <20210913112609.2651084-7-elver@google.com> Mime-Version: 1.0 References: <20210913112609.2651084-1-elver@google.com> X-Mailer: git-send-email 2.33.0.309.g3052b89438-goog Subject: [PATCH v2 6/6] workqueue, kasan: avoid alloc_pages() when recording stack From: Marco Elver To: elver@google.com, Andrew Morton Cc: Shuah Khan , Tejun Heo , Lai Jiangshan , Andrey Konovalov , Walter Wu , Sebastian Andrzej Siewior , Thomas Gleixner , 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 Tested-by: Shuah Khan Acked-by: Sebastian Andrzej Siewior --- kernel/workqueue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 33a6b4a2443d..9a042a449002 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -1350,7 +1350,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.309.g3052b89438-goog 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.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_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 3578EC433FE for ; Mon, 13 Sep 2021 11:26:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CDF8561029 for ; Mon, 13 Sep 2021 11:26:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CDF8561029 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 745646B007B; Mon, 13 Sep 2021 07:26:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F5106B007D; Mon, 13 Sep 2021 07:26:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 60B466B007E; Mon, 13 Sep 2021 07:26:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0083.hostedemail.com [216.40.44.83]) by kanga.kvack.org (Postfix) with ESMTP id 517426B007B for ; Mon, 13 Sep 2021 07:26:43 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 1A01B181AC9BF for ; Mon, 13 Sep 2021 11:26:43 +0000 (UTC) X-FDA: 78582322686.32.0614255 Received: from mail-wr1-f74.google.com (mail-wr1-f74.google.com [209.85.221.74]) by imf04.hostedemail.com (Postfix) with ESMTP id C52CC50000B3 for ; Mon, 13 Sep 2021 11:26:42 +0000 (UTC) Received: by mail-wr1-f74.google.com with SMTP id d10-20020adffbca000000b00157bc86d94eso2537437wrs.20 for ; Mon, 13 Sep 2021 04:26:42 -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=uXbisNK0hzVjo0x7v5RilsBzlcwLLC23aSoidmJI5Q0=; b=H9qgnMTa7AwCb5iArY+iTSmQ//hjkA1MCsuLuaE4/RUP/gDWt1slOPQx83Is1+UEkZ 7ldVIUBdbaEIP8vDVZbuoQ50dIniyyxtoZvPOB7cxVpBscdCyAJjLOWmnqdQeR+x+CNV R59jlsb5GGt4EU0SDMVHt3JiOYWGuHTSUdLo8AkvkHKv5yH8yYTSjCJrl4UZcNae/xqq wktQQsT9+pUVwO6scHnOqIkHX9607WZlLiri4nKPcHURD/uZZHKIepPX2DvcPENMqu+3 F0+uiIXW/gXBoLzzXUe4/bIjb/o7pcxzwMA2jaCf0hlT4hzHNQQxAMwxo+HxFlz61eyy yNow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=uXbisNK0hzVjo0x7v5RilsBzlcwLLC23aSoidmJI5Q0=; b=gfqEaCZEGIR82uYcPiy4Ah2ZjfvcHJhSTnhA635J9HA5EF2huxi6IPo8H5Z2s6mSNb wOGmES7BqSUc5uX+KzmHm0VSRkWtRIUpnSRCMZ43T3+Z6KDxerpVGYFFKde1gCjdgo/c UEDd4cIX2ayXbNXaGn13HXd0tE1awZcxIHLvsKGuE+H9oqvLL/w0PwtZ0V48F7Dst7Mz Ng6U0O3V9GTYFGxegPWytOlFuc2c8oStDQ4JaXYbc1s6oUnUouqcdW1zOFX9ylYZ5xjt 07kpYs3lIE3EaSlFhAzXsiZrX3oUNbEICH/KLV9ocly4ViJZQI2ZUKk8nRLrmK7tLQUh hWYw== X-Gm-Message-State: AOAM532y0X2UCUxVR7JgSeIg0JRyx9VKCzO/5HlGmeC+6RWdBritCKyF 93X8bqHXHhKWgIDziQqUX9OiRWQKag== X-Google-Smtp-Source: ABdhPJwrHYb2pQNJIWj/O8r94l5tGwmsJgjQ5oX69os6T91IbgkHBm7FGNsYkspC/6g0HsRIyu30TJmAcA== X-Received: from elver.muc.corp.google.com ([2a00:79e0:15:13:1f19:d46:38c8:7e48]) (user=elver job=sendgmr) by 2002:a05:600c:245:: with SMTP id 5mr9896478wmj.53.1631532401563; Mon, 13 Sep 2021 04:26:41 -0700 (PDT) Date: Mon, 13 Sep 2021 13:26:09 +0200 In-Reply-To: <20210913112609.2651084-1-elver@google.com> Message-Id: <20210913112609.2651084-7-elver@google.com> Mime-Version: 1.0 References: <20210913112609.2651084-1-elver@google.com> X-Mailer: git-send-email 2.33.0.309.g3052b89438-goog Subject: [PATCH v2 6/6] workqueue, kasan: avoid alloc_pages() when recording stack From: Marco Elver To: elver@google.com, Andrew Morton Cc: Shuah Khan , Tejun Heo , Lai Jiangshan , Andrey Konovalov , Walter Wu , Sebastian Andrzej Siewior , Thomas Gleixner , 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: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=H9qgnMTa; spf=pass (imf04.hostedemail.com: domain of 3cTU_YQUKCOgOVfObQYYQVO.MYWVSXeh-WWUfKMU.YbQ@flex--elver.bounces.google.com designates 209.85.221.74 as permitted sender) smtp.mailfrom=3cTU_YQUKCOgOVfObQYYQVO.MYWVSXeh-WWUfKMU.YbQ@flex--elver.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: C52CC50000B3 X-Stat-Signature: xp48xui5qk7z3wpzp5zbageryboribyg X-HE-Tag: 1631532402-285165 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 Tested-by: Shuah Khan Acked-by: Sebastian Andrzej Siewior --- kernel/workqueue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 33a6b4a2443d..9a042a449002 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -1350,7 +1350,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.309.g3052b89438-goog