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 2B148C83F10 for ; Thu, 31 Aug 2023 05:39:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 743648D0003; Thu, 31 Aug 2023 01:39:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F1448D0001; Thu, 31 Aug 2023 01:39:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5DF108D0003; Thu, 31 Aug 2023 01:39:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 4EC2E8D0001 for ; Thu, 31 Aug 2023 01:39:52 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1FCE4120136 for ; Thu, 31 Aug 2023 05:39:52 +0000 (UTC) X-FDA: 81183298224.02.35EF076 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by imf23.hostedemail.com (Postfix) with ESMTP id 03C0414001C for ; Thu, 31 Aug 2023 05:39:49 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=ellerman.id.au header.s=201909 header.b=q2MEeOwr; dmarc=none; spf=pass (imf23.hostedemail.com: domain of mpe@ellerman.id.au designates 150.107.74.76 as permitted sender) smtp.mailfrom=mpe@ellerman.id.au ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693460390; 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=8m/8Ci3sa8OLEyHjaXZEJTO2wXEm7Bvjz3TlOzE6bbU=; b=OMmlhX49dEKGszZ3juTd+LUS34c8ULX77rKlsZksLjQ3hmszEEAWTaQVz4heQwB3adobQc eyV1sueuq6oUwKqYthxbXmiKM8UQeZUsjRjoSipIoyjJYfcaNupnpLKml2CFNIeBmnBLYO mdlXu6WM6ASSNxoXJcnLFoG+NOqewdI= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=ellerman.id.au header.s=201909 header.b=q2MEeOwr; dmarc=none; spf=pass (imf23.hostedemail.com: domain of mpe@ellerman.id.au designates 150.107.74.76 as permitted sender) smtp.mailfrom=mpe@ellerman.id.au ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693460390; a=rsa-sha256; cv=none; b=6+zVrLaWxMlJ1x3jEXZsSrOQoZkQnmj9AXSqRX56ruz2ss7p4qw31YP2piuAuwomp4S4f7 YOTtWT91rt5XOqMo7XdPL5toJlajb1i3p5O5X4iuSV8fIoHnkopojhcTWVis/Wegrmk1ct SXrbZTovR5U17f/E3+ENMSTHdpmnO5w= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellerman.id.au; s=201909; t=1693460387; bh=8m/8Ci3sa8OLEyHjaXZEJTO2wXEm7Bvjz3TlOzE6bbU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=q2MEeOwr8M1AuORuEQ5KRfFTsIx+MHUC53Rtduh6gcGpX0Dor0A0mjF6kX6ZAYDxY huCG/u/O/1KEWUV74Xt62PpgalNhLxuG90jvRAqIPItY+4cNk0o+d3sgsR1IPWLROv kCP31+Nm86zCo0ldItGFP1lnJpUSN0/VOQKwdpqWQa6LnBcsFbUghWsnQUL/MSetvx QkjjQmLYsHGn50Xa6XoW75hIhcEztSupYHliuy+EAnntJ7pX2/FY9cZrG43M5O2f/X CXrP9HdE/rZhGCfH4SE3qbi1sGMQLcnAO6ZMi+tj9Og3NXeA57JZV4UME5UWmBSNgo HvE5CpHTw4Zjw== Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4Rbqjt6xfsz4wxN; Thu, 31 Aug 2023 15:39:46 +1000 (AEST) From: Michael Ellerman To: Geert Uytterhoeven , "Liam R. Howlett" Cc: 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 Subject: Re: [PATCH v2 1/2] maple_tree: Disable mas_wr_append() when other readers are possible In-Reply-To: <3f86d58e-7f36-c6b4-c43a-2a7bcffd3bd@linux-m68k.org> References: <20230819004356.1454718-1-Liam.Howlett@oracle.com> <20230819004356.1454718-2-Liam.Howlett@oracle.com> <3f86d58e-7f36-c6b4-c43a-2a7bcffd3bd@linux-m68k.org> Date: Thu, 31 Aug 2023 15:39:46 +1000 Message-ID: <87v8cv22jh.fsf@mail.lhotse> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 03C0414001C X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 66ytz98f7t7brk9g9twjpwec491eozaw X-HE-Tag: 1693460389-709100 X-HE-Meta: U2FsdGVkX1/Nxg+kI6clnjBk+3AFLbFDd2/Gm5L47yDOVbu94kedVe4baFXh2pSqj5/46Kyq94MMYUz+SdDsyyzAq9/9lZGRfsAoQNxJbP1ZUCAnFc+ejnvA1/ek12S8F2wDBWBeUU/yEQ7+twURbuMVmA4oVvDqfftyHr7L/EzFR1DYotTLB4c57lszeZU/3gQE5OaeCp3YWY8jQjf6TStAPxI3GYE3tZX0d63/8jkdxlomgxO4iDzvFI4ADuPT2w/l9CB2xBaAPF0n976wf3bvfn99wJR4oqa8WrdW5cFZZ1Zg7DE2kIBdR/oEVavFnoLq80SPlJf2v609j0lAhhQGfyzRJM5z3SffuoewnaEOqmRsfoPsqTbkWfDELxa2QBb6LxAWQy/0W7MpN1iO1DiWA9BUhy3/z3+ycT5s3gnFGDqhbC7cbhziqQOxBF3iXnw9adjHRFWJo1S5821+oGOxn6C+W/s82VUzapykPYcjU2vXwZ+SBcZewEnABwAfR1trFzfH3XycjOPQseqntyCEhNWoELKTsKdKP60RhdL9YsSdM6MeqC3IImgiBhINOD9tf22vGgV47W5sgwllFet8kkZXH++2xTA2moM79bdIQ1GDj347g01dKkev8iN040g3k77n8ODOQhy2+uAqzNzr4SuFO+fz6Sbn7IfiJGkxzJ/kSEgWHzu3G/sOc3wC4C9WG3A0AdQPueuoJB1UV/NIqrH1+rGIqZHeU/KxW20KDUDfV7ER+oXtQpihSwNektL7wBeGQGjX6uDY7lhrIT1OsCnKaBZnXg2g0Ey1ZxWeXU4Gt0QlIC9EGXKrC1plV3zoiSk0vNUxhBRxLXTGk7gcMMnxh4hr85nL48V8RLOcxXXMSgVtNP8TBNT2WB+rjzlqpJ08oO25D169dEtcHpLu008PbM1tdpkIN6/5MMmmnVAbHpT9AnAxRF+Zgsta2Hn67/CmblBbZRbHnFO M5wg8go/ MNiT9Ipcv94ZLy44EaOkkqiTTnSp19/n8BxKFDq5N4E7vMtYle8AClZsJr9QX0bCScXJljq2woyS4kwvWC9FG0orJqzMgjdm/nRaKjkX/CQL65tFkc+dDlVGHW1apVddqjN/DS5lgB5g3/kAe5n7Dbp6WL3X/F0D6ssUkEZqHv/15suerCYjPshf4gkgar8si7hKZB9q37Ul1wR1d9LQg4nK7TwUEEO+Wp10xlBdpLLsWTCEVEOxVa4HvOfYKgGuD2Lb0x92Pmz/aDOY9Wpk/R6ocDg== 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: Geert Uytterhoeven writes: > 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. >> >> During the analysis of the mas_next_slot() the following was >> artificially created by separating the writer and reader code: >> >> Writer: reader: >> mas_wr_append >> set end pivot >> updates end metata >> Detects write to last slot >> last slot write is to start of slot >> store current contents in slot >> overwrite old end pivot >> mas_next_slot(): >> read end metadata >> read old end pivot >> return with incorrect range >> store new value >> >> Alternatively: >> >> Writer: reader: >> mas_wr_append >> set end pivot >> updates end metata >> Detects write to last slot >> last lost write to end of slot >> store value >> mas_next_slot(): >> read end metadata >> read old end pivot >> read new end pivot >> return with incorrect range >> set old end pivot >> >> There may be other accesses that are not safe since we are now updating >> both metadata and pointers, so disabling append if there could be rcu >> readers is the safest action. >> >> Fixes: 54a611b60590 ("Maple Tree: add new data structure") >> Cc: stable@vger.kernel.org >> Signed-off-by: Liam R. Howlett > > Thanks for your patch, which is now commit cfeb6ae8bcb96ccf > ("maple_tree: disable mas_wr_append() when other readers are > possible") in v6.5, and is being backported to stable. > > On Renesas RZ/A1 and RZ/A2 (single-core Cortex-A9), this causes the > following warning: > > clocksource: timer@e803b000: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 28958491609 ns > sched_clock: 32 bits at 66MHz, resolution 15ns, wraps every 32537631224ns > /soc/timer@e803b000: used for clocksource > /soc/timer@e803c000: used for clock events > +------------[ cut here ]------------ > +WARNING: CPU: 0 PID: 0 at init/main.c:992 start_kernel+0x2f0/0x480 > +Interrupts were enabled early ... > > I do not see this issue on any other platform > (arm/arm64/risc-v/mips/sh/m68k), several of them use the same > RCU configuration. There's something similar on pmac32 / mac99. > Do you have a clue? It seems something in the maple tree code is setting TIF_NEED_RESCHED, and that causes a subsequent call to cond_resched() to call schedule() and enable interrupts. On pmac32 enabling CONFIG_DEBUG_ATOMIC_SLEEP fixes/hides the problem. But I don't see why. cheers