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 642A3CA0ECF for ; Tue, 12 Sep 2023 10:00:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EB47B6B00CD; Tue, 12 Sep 2023 06:00:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E63AF6B00D0; Tue, 12 Sep 2023 06:00:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D539F6B00D1; Tue, 12 Sep 2023 06:00:19 -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 C578B6B00CD for ; Tue, 12 Sep 2023 06:00:19 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 99D5CB3FBA for ; Tue, 12 Sep 2023 10:00:19 +0000 (UTC) X-FDA: 81227500158.01.85FB69E Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf10.hostedemail.com (Postfix) with ESMTP id 14E4FC001D for ; Tue, 12 Sep 2023 10:00:16 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Y5JnVKpr; spf=pass (imf10.hostedemail.com: domain of "SRS0=rctY=E4=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=rctY=E4=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org"; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694512817; h=from:from:sender:reply-to: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+t9fSPoNNyuydzod9FJDLrYJiAEkBOm5CmfSdcikGOA=; b=Z/g8FxgGQJskk+sXQ+W5fAFna5UhEBdUuivbmYWyKUL8h9yEFYq+HMqwvqCu6RLnuubZ5O wKIcy+S3Bo12c2ddCMBf0PNSNqnkJocRWvumRUboLzVqWNgFe4Mw0uFKMzGfHGS+1aR6Qs 2/jXPlAHlVu9WI9pIlBZSCI8Ze2nxeA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694512817; a=rsa-sha256; cv=none; b=PDD48wD2wMqkfOsK3hgETMo8LjOXbuWtr6DAx4x4KWS9AWJa0SOK4rrsnsTPN7yw0KlJSK kmGGx/LChQ+zoWegxUa7vKGUYIJpuXwciZ/nO8apmUirWzE6DYSdadogOHySh6hUEWp9Fx cb1HRrXeqieh1h3/FLi3VEZPqAUXkZ8= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Y5JnVKpr; spf=pass (imf10.hostedemail.com: domain of "SRS0=rctY=E4=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=rctY=E4=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org"; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 5DED4CE1B5B; Tue, 12 Sep 2023 10:00:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AEF53C433D9; Tue, 12 Sep 2023 10:00:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1694512811; bh=2QOrKx+Xb+EJ5/74k7kuwKb8czGo2OeeiPj5tdU/8Xk=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=Y5JnVKprj6bUwUEkD9rsCe2ACaJTIlMGY5JQ3MLcWfS6rdJMhVwwX49jpA5AdR+pT DQuYBwtHeCumymdRH/g8yBYd1vOsQnYifdOZUPwN3qiNAJ8G5Ru2l+d2neRCdQuikt R9V/f3VnBRhrD4qNgpLmBg49BNgjZu17qgs7PEKbD73O+p00MG0t6i8vNn8DiPVDI7 vBEGcchvI/eD7sOSD+C92xK5++EypyGdLr9twR5Ah8yjeFE6kQXHpnJkh8RsCnBvvc 5uVPHjAqWqKU+Ct6S8CeIiFRXFkCsNpe1fkTevf1YQtxsiqoIVg/rOWhAcgs6ENQ9h j6k+U780tbKmg== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 3F486CE093C; Tue, 12 Sep 2023 03:00:11 -0700 (PDT) Date: Tue, 12 Sep 2023 03:00:11 -0700 From: "Paul E. McKenney" To: Geert Uytterhoeven Cc: "Liam R. Howlett" , Andrew Morton , maple-tree@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Shanker Donthineni Subject: Re: [PATCH v2 1/2] maple_tree: Disable mas_wr_append() when other readers are possible Message-ID: <62936d98-6353-486e-8535-86c9f90bc7f4@paulmck-laptop> Reply-To: paulmck@kernel.org References: <3f86d58e-7f36-c6b4-c43a-2a7bcffd3bd@linux-m68k.org> <20230906152325.dblzauybyoq5kd35@revolver> <20230906172954.oq4vogeuco25zam7@revolver> <495849d6-1dc6-4f38-bce7-23c50df3a99f@paulmck-laptop> <20230911235452.xhtnt7ply7ayr53x@revolver> <33150b55-970c-4607-9015-af0e50e4112d@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 14E4FC001D X-Rspam-User: X-Stat-Signature: wjafu5gdtd8qefw3qgjx6dwauubdccnn X-Rspamd-Server: rspam03 X-HE-Tag: 1694512816-549106 X-HE-Meta: U2FsdGVkX182A3A/VjUiZdOAYMHj2VTj63L+hIRwKlAeXr91YFJN+R1bZ+465sXYBBnJ1Zj11CUqLRhKAQRVuFXBD35bT94ablkowPyAger56aOlEb8BaJYcUVIF8lc+cjIHnbA50jQlT/s7Ff7FIspQBBDIcvjPSXwVZmgzcgn+z8QPUevH4qz05efI6mQOK0rasBZubjDQhizyN1g5URmGVhBV03jGEfWKIv6IOoncyxlS/A0oFA32qzvIztzdOO632SxyKndOJzTpgHuOtz/U7CX8gGQptQU3JfLPD7RTDaMI2g85OSTSYzLhcVsBoCFc3i+5ovqWWZ0gzQFX9LF4Vq/5N3OgmZKAC3ObiXF9gmdwW77kHiK+Phlg3MY4RgCPZjPzKgSYUkimRKgpK68xV3/8YfBpdpz2CnBq3RnlyuxNRe+ipPwUTraGa4Ctyw3SV2h8JlGGU1ylYt8Jfy0Tuqc830+oGIyqbZ5b16rhdQJMOaY1p2Rj/uG1XHyhJ9EFQnRRQacNBvz171aP2+t2WHOfOXQoF2ZaamrF0Vyuf6hvYiCb1czpT1+kXipS9NhW7Lv7tQNi8PVe71YFm5uCnv4aWrASrD5Pw597EMxtZLOi9umg2nB7ew76BuyMz4tw0dTN7AD6gDbCniF/+sWigIgvfWNFGakwSal3n3D4qwYk3hgQsZum20oAixqYC9BNJynEm6JhQdanrNGMZlepZaE7seHEI0RZnc8i4k1NUBc9Yqsd7fXItPfd5xJPc0CCGJ8046bkFZ2gynTu1pVeaOTUVOYj42CUOOpfKyIMeKms8Iz67Cg2LNe2UZuyMD6g8xQfYgFoYXSemZ1zIBrpzQsaBidIUGRPisVx/mXtAf8zK8ieoXzsUj2BeT7LoB6luqorxaKJ+Wmrjj3vA+GlzbuRuKZx2hKXV56CyqCr3MOccm6z58ITP1GwEpddw7SLsGuC2fB7c5e3iwl y41XR7QO r4f1yu/Ksayvy+6C2uyKKIodI4+CPVCEaNEX/V7VmS7JfawVmcb27x5ws2Oy1hoMnJeqTpg0cDP6Pi80MLCTgkkj0av32A/RPyrpaI2rQ4KZVHe7804hU9WKE+D5F7CWiSiRrgb+VFEpMkD5HoqJhwmbDam8QXy8vo6CUDeaFQD2CHPyacC+woHxfwsA+Kn4tipE6pU7bJrUBGzBFldRXh+dmKSSO35ZHf90uHGi2k7TE/Psw6wdqmaiFx6gC+nFnyKmKEdshu+UzYJX4HKgWD6aCyBc5fNr6H7KF/tvpsI2b1svYSLqKsqwIuIjU1JErkceXyfdl31LKh7u0uAQtnU0Mc7l8F42U+i+6RwluB7D+3Dckcdp2OYl7zZXsUrYNwdgP+qXCUI1EGwXRw+ZsGTkFXm+HLO0yhregOTB1nnJzAgz5DTZn+QP0AWu07WkoTdJSBqBXl5FbfsPnBGyLTvHa8tH4axAqH6AbT0AlquvwNk6lENbcFOlr85NviJ9NQlSPytqNn0DhmcBwH/KxFs4c9QkgGKOZza/RLckeRTTLJGx9oLqu75YrbwdjrgfCPJqBRX3UuXiukmZBE+sn+Jo7FgfjIC0MGQIJWr+L24DRn1cTl/RyB8Fkzbj2w3bBjUhu7YIFXvLlgggG7EvOCAlzel+MaIcr+b5w0GM46hzz1YjnrQSj4/sSU+ZuVD0Fd7rL6AgyAENn/nACasi+ONQQsjoaQXoQ5sxJQR8716VLwCAqLUc64LA2vqbSO3kjBTK45JGZQqd9+JP1+E6uaHoAJ9aMdYgvto5pfv54bKUznxU= 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 Tue, Sep 12, 2023 at 10:34:44AM +0200, Geert Uytterhoeven wrote: > Hi Paul, > > On Tue, Sep 12, 2023 at 10:30 AM Paul E. McKenney wrote: > > On Tue, Sep 12, 2023 at 10:23:37AM +0200, Geert Uytterhoeven wrote: > > > On Tue, Sep 12, 2023 at 10:14 AM Paul E. McKenney wrote: > > > > On Mon, Sep 11, 2023 at 07:54:52PM -0400, Liam R. Howlett wrote: > > > > > * Paul E. McKenney [230906 14:03]: > > > > > > On Wed, Sep 06, 2023 at 01:29:54PM -0400, Liam R. Howlett wrote: > > > > > > > * Paul E. McKenney [230906 13:24]: > > > > > > > > On Wed, Sep 06, 2023 at 11:23:25AM -0400, Liam R. Howlett wrote: > > > > > > > > > (Adding Paul & Shanker to Cc list.. please see below for why) > > > > > > > > > > > > > > > > > > Apologies on the late response, I was away and have been struggling to > > > > > > > > > get a working PPC32 test environment. > > > > > > > > > > > > > > > > > > * Geert Uytterhoeven [230829 12:42]: > > > > > > > > > > Hi Liam, > > > > > > > > > > > > > > > > > > > > On Fri, 18 Aug 2023, Liam R. Howlett wrote: > > > > > > > > > > > The current implementation of append may cause duplicate data and/or > > > > > > > > > > > incorrect ranges to be returned to a reader during an update. Although > > > > > > > > > > > this has not been reported or seen, disable the append write operation > > > > > > > > > > > while the tree is in rcu mode out of an abundance of caution. > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > RCU-related configs: > > > > > > > > > > > > > > > > > > > > $ grep RCU .config > > > > > > > > > > # RCU Subsystem > > > > > > > > > > CONFIG_TINY_RCU=y > > > > > > > > I must have been asleep last time I looked at this. I was looking at > > > > Tree RCU. Please accept my apologies for my lapse. :-/ > > > > > > > > However, Tiny RCU's call_rcu() also avoids enabling IRQs, so I would > > > > have said the same thing, albeit after looking at a lot less RCU code. > > > > > > > > TL;DR: > > > > > > > > 1. Try making the __setup_irq() function's call to mutex_lock() > > > > instead be as follows: > > > > > > > > if (!mutex_trylock(&desc->request_mutex)) > > > > mutex_lock(&desc->request_mutex); > > > > > > > > This might fail if __setup_irq() has other dependencies on a > > > > fully operational scheduler. > > > > > > > > 2. Move that ppc32 call to __setup_irq() much later, most definitely > > > > after interrupts have been enabled and the scheduler is fully > > > > operational. Invoking mutex_lock() before that time is not a > > > > good idea. ;-) > > > > > > There is no call to __setup_irq() from arch/powerpc/? > > > > Glad it is not just me, given that I didn't see a direct call, either. So > > later in this email, I asked Liam to put a WARN_ON_ONCE(irqs_disabled()) > > just before that mutex_lock() in __setup_irq(). > > > > Either way, invoking mutex_lock() early in boot before interrupts have > > been enabled is a bad idea. ;-) > > I'll add that WARN_ON_ONCE() too, and will report back later today... Thank you, looking forward to hearing the outcome! > > > Note that there are (possibly different) issues seen on ppc32 and on arm32 > > > (Renesas RZ/A in particular, but not on other Renesas ARM systems). > > > > > > I saw an issue on arm32 with cfeb6ae8bcb96ccf, but not with cfeb6ae8bcb96ccf^. > > > Other people saw an issue on ppc32 with both cfeb6ae8bcb96ccf and > > > cfeb6ae8bcb96ccf^. > > > > I look forward to hearing what is the issue in both cases. > > For RZ/A, my problem report is > https://lore.kernel.org/all/3f86d58e-7f36-c6b4-c43a-2a7bcffd3bd@linux-m68k.org/ Thank you, Geert! Huh. Is that patch you reverted causing Maple Tree or related code to attempt to acquire mutexes in early boot before interrupts have been enabled? If that added WARN_ON_ONCE() doesn't trigger early, another approach would be to put it at the beginning of mutex_lock(). Or for that matter at the beginning of might_sleep(). Thanx, Paul