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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2F223E6F085 for ; Fri, 1 Nov 2024 19:51:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 862DB6B0096; Fri, 1 Nov 2024 15:51:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 811E76B0098; Fri, 1 Nov 2024 15:51:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68C026B0099; Fri, 1 Nov 2024 15:51:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 45E706B0096 for ; Fri, 1 Nov 2024 15:51:48 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C1313160DB3 for ; Fri, 1 Nov 2024 19:51:47 +0000 (UTC) X-FDA: 82738569522.20.BAD85A4 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) by imf10.hostedemail.com (Postfix) with ESMTP id DCB1BC0013 for ; Fri, 1 Nov 2024 19:51:32 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=g7SYZYDM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf10.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.222.179 as permitted sender) smtp.mailfrom=boqun.feng@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730490649; a=rsa-sha256; cv=none; b=ME4JQM8mNB1ETTrg3XH8hXrt1BnK+jp7zO/UasZWIzQA/eUFzlWLO3OksyU4c1QWxmwvK7 KHMxlRQQGDTvnk41SMCI5NHMXzl6XD7xAWX7OpWudXVg93qxDCjg8Iy71tWTVECEhqebzC S1hb8nsHPZ9nn+dkndrVq7MgG7CIwm8= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=g7SYZYDM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf10.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.222.179 as permitted sender) smtp.mailfrom=boqun.feng@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730490649; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/Zt5Oyq2ZbDc+xfDrPzoymFKTcNzDTK9mifrrmXHggY=; b=sTvdiBIw1o2JW5PAuh3AvFL84Zv5qutwEnKygXfKMhXVgRD7eeCl0HV8jNMjXL2yIbMzBR wBhi8GTxOVOZCeShRkLWC+6dmbyGkzb8gH4psJ85pe7UPRgrkZx7RiQGJncfz5cCFmr2Iq wM/kVEoCSxmU0tJsaAdw1sgZRYvTlik= Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-7b1511697a5so159071585a.2 for ; Fri, 01 Nov 2024 12:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730490704; x=1731095504; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=/Zt5Oyq2ZbDc+xfDrPzoymFKTcNzDTK9mifrrmXHggY=; b=g7SYZYDMqvEU3tfUrQkSXs9q5065hWYSg16b/fuyEwjDvxuDN5Q8jgnSEwXxLKmOmR 7yUKIuPIyQGJJFLaAXiIDSZFJINyU9Kaw6ut5dyv2WA+yoGHp6E4mFnDwFnNSEo2+eSJ p52gg0PRS5pFzlyTLlpFB0xW2mJVVx9yjQims4ZUmJ3+H+1cUBnCgjFnQiIgLm2DCrIQ GdgZQOVTda4vNi9AQNMO7EpJ9lZEMnvUQkJpETrd2Wf0wGUn3aLWpoP8+qG4/F0dBsuu iM1WlQlU2iLzRb5lnusi3Hj1IXuzbmS9YQSukcYKI/YG6/um++l5TZTITqQIepHxL0k+ NLqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730490704; x=1731095504; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/Zt5Oyq2ZbDc+xfDrPzoymFKTcNzDTK9mifrrmXHggY=; b=LUuji803BATW3Bw5yJaYyYBwzCogYu6UcndZbE5SxOtssId/pQrByt40cDqZtJWEbk e05mYLBiay5XnmXBUIJ5mcd6AVGydaC8z1ZKYHHuJFX6WDSUbBltpk3kBeRutvm28Zzy 27+NoP/Kz9Zr6/PbL/mQWyjXSU76EpztO42vFhqx9wfOV8fXWgUdqV2zyhAwwTlPrfjy HKIaD97sLgRKbibDfd5l1Mfo4OJO6Ay9rMOYQIvrY9cvwEjAzwLYV3NZGant1WQ/kmHJ nFBfEyQTZ1/COUvtxGzd3WE00tUH57SI6N4muVBHz6gP2r+hetvRFGqnRfIlnOoMb/JF yLYg== X-Forwarded-Encrypted: i=1; AJvYcCW3PaHIKzzlZZL+0beXuNyXlPzJWofz1ktjJM2HEfPuw2FXeePBwUFTFk6t+K5QEfmf4QlSU7WotA==@kvack.org X-Gm-Message-State: AOJu0YzmZiToBz/9nn7UbYb7QBBHnB5JfLBbIxJKLcpUJKyTPzWqz14d 5XBaaO9FRsyLVI2/LsNWVaOpbQCEt0egG3RbuH0o5PyZnZX1cjak X-Google-Smtp-Source: AGHT+IGLRucb60qWSoDzC20ZGsm0aymAio3/wRy2855/uIReTW6N0UKUogGsYjz5TRM/PQshs5hkKQ== X-Received: by 2002:a05:620a:2410:b0:7ac:b220:309a with SMTP id af79cd13be357-7b193eea86cmr3366675785a.15.1730490704526; Fri, 01 Nov 2024 12:51:44 -0700 (PDT) Received: from fauth-a2-smtp.messagingengine.com (fauth-a2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7b2f3a6fedcsm199163285a.78.2024.11.01.12.51.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Nov 2024 12:51:44 -0700 (PDT) Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfauth.phl.internal (Postfix) with ESMTP id 981A91200043; Fri, 1 Nov 2024 15:51:43 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Fri, 01 Nov 2024 15:51:43 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdekledguddvlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddv necuhfhrohhmpeeuohhquhhnucfhvghnghcuoegsohhquhhnrdhfvghnghesghhmrghilh drtghomheqnecuggftrfgrthhtvghrnhephedugfduffffteeutddvheeuveelvdfhleel ieevtdeguefhgeeuveeiudffiedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepsghoqhhunhdomhgvshhmthhprghuthhhphgvrhhsohhnrghl ihhthidqieelvdeghedtieegqddujeejkeehheehvddqsghoqhhunhdrfhgvnhhgpeepgh hmrghilhdrtghomhesfhhigihmvgdrnhgrmhgvpdhnsggprhgtphhtthhopeduiedpmhho uggvpehsmhhtphhouhhtpdhrtghpthhtohepphgruhhlmhgtkheskhgvrhhnvghlrdhorh hgpdhrtghpthhtohepsghighgvrghshieslhhinhhuthhrohhnihigrdguvgdprhgtphht thhopehvsggrsghkrgesshhushgvrdgtiidprhgtphhtthhopegvlhhvvghrsehgohhogh hlvgdrtghomhdprhgtphhtthhopehlihhnuhigqdhnvgigthesvhhgvghrrdhkvghrnhgv lhdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnh gvlhdrohhrghdprhgtphhtthhopehkrghsrghnqdguvghvsehgohhoghhlvghgrhhouhhp shdrtghomhdprhgtphhtthhopehlihhnuhigqdhmmheskhhvrggtkhdrohhrghdprhgtph htthhopehsfhhrsegtrghnsgdrrghuuhhgrdhorhhgrdgruh X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 1 Nov 2024 15:51:43 -0400 (EDT) Date: Fri, 1 Nov 2024 12:50:30 -0700 From: Boqun Feng To: "Paul E. McKenney" Cc: Sebastian Andrzej Siewior , Vlastimil Babka , Marco Elver , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, sfr@canb.auug.org.au, longman@redhat.com, cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org Subject: Re: [BUG] -next lockdep invalid wait context Message-ID: References: <41619255-cdc2-4573-a360-7794fc3614f7@paulmck-laptop> <66a745bb-d381-471c-aeee-3800a504f87d@paulmck-laptop> <20241031072136.JxDEfP5V@linutronix.de> <20241031075509.hCS9Amov@linutronix.de> <186804c5-0ebd-4d38-b9ad-bfb74e39b353@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <186804c5-0ebd-4d38-b9ad-bfb74e39b353@paulmck-laptop> X-Rspam-User: X-Rspamd-Queue-Id: DCB1BC0013 X-Rspamd-Server: rspam01 X-Stat-Signature: w8rkqxb5zcscoodea1wna3yz4jeqr5m6 X-HE-Tag: 1730490692-670560 X-HE-Meta: U2FsdGVkX18ruzgBBcFR0r7M1U9EVv2OkjblXYFCpj+ycfdspH1V1+B0Pv9DlwzxZp/hU4Octz/DBIjzFlF79C/CLd7nhihysSoH/zSKCEmYZ+83KLnFJYz7UTWJvC13OvEqDX7owvui724EXeTuil31y+ECwzxqiDYFA1Jlb8TnTGshdIgYPgfLI/mN3GCrsXHf/TUKxNjBYB9GBp8MZwyC4oSGz+VYA4Dup5gVsmdzHZgf9tQIMTbKFM3qwXBc8ekcvCKO5R5ZHQWsb55fZ8cIfQeGmHgpRx3aaXi+4D0QQt9IsG3wKI2PZmk3/yPFZKgNj/TB+leDckiC8ZIgSoYjiEVntSp7nAa2kMdz1DfuC2jrERp/Qnq+bBn6Y42X1gtSEtBoQ56ydf/Lewq1khvKXb4cjQoxbuateZ/gt/jSlAbHccZmvqn5mxS7eZA/TiUvgymdtoFIIfnMd6i7OelXhFAtxcVJtGBbqBjy0S+iUvsyADCPXE5f3MgsPpohw0bdM/O5jLmY65X9mCoY8C92mqqEdr4hdGxbdfd1OSDICPpMTXD5eHtkRuMncIu/E+/BrX/VG5nZv1Xm+j/JH9E9SLir6u1hc6OAzvtmzwE72Wn1ArmWJ/RDkt9orA1TLCADZ0Nr96S/LmVTbxg0x6xQoy3MeM+ecyuhD4aPSGV+U5vGxtWethom1JVLLx/fl2dVRt0goZlgkg1Z1ROJa9L3P9hx4Pi/mCYPvuzcPemBS4eYn7HN6su78+YxTBGzgdgdZgQp6CxkifQHHlwztNS4UTTjLLp7nXuMCE6S2MK3iorFNw+HZPgU0n3dw2NDtSsvRuk3M8LE/QedCrlPymL8Pg5CA13HSO1wUi2b+8eF143H0QnBWNTTz/bEK36+IH2TGR/owfnIHuTTGBZsQA1UIsCLk1tY0phv718NvkhhMew1SWalwU81EYyrRqQSoJLzvu/q5VgcAorAvgR qTLFwKWP TSNqlAc1gng4g+kdvSevz98++Etb3G54rndb4BtyL3XFk4fVEnglWzmMYm3Pooh+KLh7feojmpmC9FvF3xmNtjZQ7qM8MXb7rIki3zPfn21wL+P7763rW5+jaASdWt3MjSs30w8fMzifWeoQmkmgHkO9cUXm64oS6OgFpYROzy9VxjJ/7WYfbjID4PuRKmgb+xShcm2HL6EEyMflLCGBO6h6EDFUdVqRK5oyLy7/N8e3IOTKXfO5oimilmXIeS49cAGyoWSdcngnk9fc71l+B446QeaAFQju4R9d2TOBVyRTrmv1XlCFl6MxqSkBAUhQCJa4AtXNYpBXEIL3QZ1KiY5nGtRTSBllbcZqbMU/GrGvKrRuut7hQbBhMlWifdshLA7O/ 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: List-Subscribe: List-Unsubscribe: On Thu, Oct 31, 2024 at 10:50:29AM -0700, Paul E. McKenney wrote: > On Thu, Oct 31, 2024 at 08:55:09AM +0100, Sebastian Andrzej Siewior wrote: > > On 2024-10-31 08:35:45 [+0100], Vlastimil Babka wrote: > > > On 10/31/24 08:21, Sebastian Andrzej Siewior wrote: > > > > On 2024-10-30 16:10:58 [-0700], Paul E. McKenney wrote: > > > >> > > > >> So I need to avoid calling kfree() within an smp_call_function() handler? > > > > > > > > Yes. No kmalloc()/ kfree() in IRQ context. > > > > > > However, isn't this the case that the rule is actually about hardirq context > > > on RT, and most of these operations that are in IRQ context on !RT become > > > the threaded interrupt context on RT, so they are actually fine? Or is smp > > > call callback a hardirq context on RT and thus it really can't do those > > > operations? > > > > interrupt handlers as of request_irq() are forced-threaded on RT so you > > can do kmalloc()/ kfree() there. smp_call_function.*() on the other hand > > are not threaded and invoked directly within the IRQ context. > > OK, thank you all for the explanation! I will fix using Boqun's > suggestion of irq work, but avoiding the issue Boqun raises by invoking I've tried fixing this with irq work, however, unlike normal work_struct, irq_work will still touch the work item header after the work function is executed (see irq_work_single()). So it needs more work to build an "one-off free" functionality on it. I think we can just use normal workqueue, because queue_work() uses local_irq_save() + raw_spin_lock(), so it's irq-safe even for non-threaded interrupts. Sending a patch soon. Regards, Boqun > the irq-work handler from the smp_call_function() handler. > > It will be a few days before I get to this, so if there is a better way, > please do not keep it a secret! > > Thanx, Paul