Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3509764ybb; Tue, 31 Mar 2020 06:45:15 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuODb+RnNqyhMAyRgI2o49deL6LN2PMOk6F0b4M+KbC/13PCMWXHlpDTuJKfLaR+WmYGFP+ X-Received: by 2002:a05:6830:10a:: with SMTP id i10mr13460389otp.190.1585662314992; Tue, 31 Mar 2020 06:45:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585662314; cv=none; d=google.com; s=arc-20160816; b=SpLADgvawm1AZOskXtps/hIPrwHhDUdKc/y3cSpw6cFYOmAtZWKMor3kCo+pyT5tMq 51kSJxwGm8nUSFDHDrRp/JF0Gk1iaEjYkraKhxX1DhuK3TpbzTdbzCxp4sWDOdKqVbAz OlC+AvyC46h6Ey2KXx8/qdv+53E/A4NWm+WCQM46bCE6q3mtOP0BU5Va7ep3Qq7iP9v7 bgFvOSplPPGDWOX35oqxXHbgcOb3Ucn2z5jTO1ViDq0VXHMoKtLd2//y28ligGtU08Va lvf069WBmk/ajFVuEAodj0D6GxW0QSc5/MLuB4aP1AbbtQVThqy27u58JvAez2pNQl6+ vqNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=g18bas2a3VURd/1hd0wl0RzndDbmt66BF654y73YqBM=; b=bPcqZScAp0AQI58L/WoH5yZV/FnRQANfczMuPFnlp7P9wIey2WQPCR4OMJk7SYjgWG BNYp+ZbnJz8w71bMaQy/dMX3eoRz4KAvNkjGcMng8Yq7ANnF6V+is+Ej3uhiqq+o/QeL rTuhfZyfAfAIMeJkpmzncl0mbKYoTinRTl6YFtdGAxiQc/Sy1KRI8binZhryhQSgdWOd xpLN8WMpY468xfa3e3e2BDFsfO9TY7P4GXw96KH79yHHXQz3HqFp0rpYMCqZE6J614+o sJbLfI/lRuxa53bjhnrtjt2vn0Nj+YZnTNGRnUwLCDX+8duVbYjW6va6U8LUKkKUJbEy oWpw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k185si7192413oif.13.2020.03.31.06.45.01; Tue, 31 Mar 2020 06:45:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730946AbgCaNm4 convert rfc822-to-8bit (ORCPT + 99 others); Tue, 31 Mar 2020 09:42:56 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:33017 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730216AbgCaNm4 (ORCPT ); Tue, 31 Mar 2020 09:42:56 -0400 Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1jJHAH-00038x-K6; Tue, 31 Mar 2020 15:42:49 +0200 Date: Tue, 31 Mar 2020 15:42:49 +0200 From: Sebastian Andrzej Siewior To: Geert Uytterhoeven Cc: Peter Zijlstra , Linux Kernel Mailing List , Ingo Molnar , Will Deacon , "Paul E . McKenney" , Joel Fernandes , Steven Rostedt , Linus Torvalds , Thomas Gleixner , Linux ARM , Russell King , Catalin Marinas Subject: Re: [PATCH 6/9] lockdep: Introduce wait-type checks Message-ID: <20200331134249.kf3zyf27xtspmlif@linutronix.de> References: <20200313174701.148376-1-bigeasy@linutronix.de> <20200313174701.148376-7-bigeasy@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-03-31 15:25:21 [+0200], Geert Uytterhoeven wrote: > Hi all, Hi Geert, > On arm64 (e.g. R-Car H3 ES2.0): > > +============================= > +[ BUG: Invalid wait context ] > +5.6.0-salvator-x-09423-gb29514ba13a9c459-dirty #679 Not tainted > +----------------------------- > +swapper/5/0 is trying to lock: > +ffffff86ff76f398 (&pool->lock){..-.}-{3:3}, at: __queue_work+0x134/0x430 The pool->lock is not yet converted. … > On arm32 (e.g SH-Mobile AG5, using Cortex-A9 TWD): > > +============================= > +[ BUG: Invalid wait context ] > +5.6.0-kzm9g-09424-g2698719b4c4f35db-dirty #253 Not tainted > +----------------------------- > +swapper/0/0 is trying to lock: > +dfbc5250 (&pool->lock){..-.}-{3:3}, at: __queue_work+0x14c/0x4d0 same issue. > I also see it on other arm32 platforms using Renesas-specific timers, > but I'll ignore those until the issues with "standard" ARM timers have > been resolved ;-) There are some known culprits, like the work infrastructure. The printk is another one. From Kconfig: | 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 permanentely enabled once the main issues have been fixed. > Thanks! > > Gr{oetje,eeting}s, > > Geert > > Sebastian