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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 EFD9FC4338F for ; Sun, 15 Aug 2021 10:42:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 996F060EE4 for ; Sun, 15 Aug 2021 10:42:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 996F060EE4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 349CC6B006C; Sun, 15 Aug 2021 06:42:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2FAA16B0071; Sun, 15 Aug 2021 06:42:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 20FDC6B0072; Sun, 15 Aug 2021 06:42:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0069.hostedemail.com [216.40.44.69]) by kanga.kvack.org (Postfix) with ESMTP id 09B116B006C for ; Sun, 15 Aug 2021 06:42:56 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id A5AAB8249980 for ; Sun, 15 Aug 2021 10:42:55 +0000 (UTC) X-FDA: 78476977110.33.37CB97C Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf28.hostedemail.com (Postfix) with ESMTP id 64A9F900C524 for ; Sun, 15 Aug 2021 10:42:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Aoe4jfbdTa0I1jWe9MNGOc2P7NMzebyR5RRyvphdXHU=; b=o/PzNz0Vha0sORW1pzVM1cVryf VDemxf4GQT8jxX5OSLY48RePPn1A1La567+yOnNMZ/wGMIaC0PG9hCL+G+xdjfuXSpFOb/8hmvCA8 PGOq1ijCq5prwExpVl4J7qaaHmfz73I9dTi5Vv7ZVAYATwFp2M9k1Bm/5HB52dMNudfHCarTLKEg+ 3BL8mHCfLzLWE0H44+qn77L9mbhqNw9aDcmutf20IznMkrIDQgSLhrIBA6p/jPHQAiZYUWK1c0xWY QT+THa0Uj8hD4O8Lxh9KrmbDfRUvQQpe1AjqtIj57J2hFnk95lG1x259E8l98Cr3t2+sbpj7kKTf+ VR8oU5aw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mFDaa-0004U7-3p; Sun, 15 Aug 2021 10:42:09 +0000 Date: Sun, 15 Aug 2021 11:42:00 +0100 From: Matthew Wilcox To: Tetsuo Handa Cc: Thomas Gleixner , Zqiang , Kees Cook , Stephen Boyd , Tejun Heo , Lai Jiangshan , Peter Zijlstra , Ingo Molnar , Will Deacon , Waiman Long , Boqun Feng , linux-mm Subject: Re: [5.14] problem with dynamic memory allocation for object debugging Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 64A9F900C524 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="o/PzNz0V"; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Rspamd-Server: rspam01 X-Stat-Signature: szm1bhm7rat95464wjkxdgc4dubi6373 X-HE-Tag: 1629024175-990723 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 Sun, Aug 15, 2021 at 07:23:03PM +0900, Tetsuo Handa wrote: > Hello. > > I'm frequently hitting "BUG: Invalid wait context", and > it seems that this problem is not fixed yet. > > This is a problem between spinlock versus raw_spinlock. check_wait_context() > complains if we try to take a spinlock when we already hold a raw_spinlock. Disable this option: config PROVE_RAW_LOCK_NESTING bool "Enable raw_spinlock - spinlock nesting checks" depends on PROVE_LOCKING default n help Enable the raw_spinlock vs. spinlock nesting checks which ensure that the lock nesting rules for PREEMPT_RT enabled kernels are not violated. NOTE: There are known nesting problems. So if you enable this option expect lockdep splats until these problems have been fully addressed which is work in progress. This config switch allows to identify and analyze these problems. It will be removed and the check permanently enabled once the main issues have been fixed. If unsure, select N. If you're not working on removing these splats yourself, then reporting them has little value.