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 580D9C6FA8F for ; Tue, 29 Aug 2023 16:42:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 76FCA8E0029; Tue, 29 Aug 2023 12:42:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 71FF18E001A; Tue, 29 Aug 2023 12:42:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 60E678E0029; Tue, 29 Aug 2023 12:42:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 51D2F8E001A for ; Tue, 29 Aug 2023 12:42:54 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 20F9B140244 for ; Tue, 29 Aug 2023 16:42:54 +0000 (UTC) X-FDA: 81177711468.12.F96DA15 Received: from laurent.telenet-ops.be (laurent.telenet-ops.be [195.130.137.89]) by imf20.hostedemail.com (Postfix) with ESMTP id 4E8631C0003 for ; Tue, 29 Aug 2023 16:42:52 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=none; dmarc=none; spf=none (imf20.hostedemail.com: domain of geert@linux-m68k.org has no SPF policy when checking 195.130.137.89) smtp.mailfrom=geert@linux-m68k.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693327372; a=rsa-sha256; cv=none; b=5KGycNCDhb9+PJxtf389Dm2Bsrt6UBn4IcJzvivR0U7I2hs/hc/kdfATFA60lAOjED5Qej s22urUF+jKSAlC7gMwPGBAMo7NJcl/I01bh4QM/o2rCEXI+4qXtgsRYsicpuIYQhgQeQVE AH0Ga/e9WkTCJxUfrRRmSFOf4G0g+c0= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; dmarc=none; spf=none (imf20.hostedemail.com: domain of geert@linux-m68k.org has no SPF policy when checking 195.130.137.89) smtp.mailfrom=geert@linux-m68k.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693327372; 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; bh=wASviVtke/KgEeGLZ/1WpcF7ZPKBW9MntMSUcvEvzsw=; b=kbSz7yxApJdbcx5Vh+MirQ/Jto+kqNVzLVSsJRk6PntmWOYFnT/Hm1ixQPNicyYDkic55V fWREXu4+7Z9EhOaHxObuBf284hU/wPRrrMvpDznn0grG/8wArJkv+4KW35F68rVUmkiGKs uFF/A+wd90L5n4eqfyBRx3YxqlG0+eE= Received: from ramsan.of.borg ([IPv6:2a02:1810:ac12:ed40:c79b:b256:edee:805c]) by laurent.telenet-ops.be with bizsmtp id fUio2A00927hkyq01UioRU; Tue, 29 Aug 2023 18:42:50 +0200 Received: from geert (helo=localhost) by ramsan.of.borg with local-esmtp (Exim 4.95) (envelope-from ) id 1qb1nk-002041-8E; Tue, 29 Aug 2023 18:42:48 +0200 Date: Tue, 29 Aug 2023 18:42:48 +0200 (CEST) From: Geert Uytterhoeven To: "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: <20230819004356.1454718-2-Liam.Howlett@oracle.com> Message-ID: <3f86d58e-7f36-c6b4-c43a-2a7bcffd3bd@linux-m68k.org> References: <20230819004356.1454718-1-Liam.Howlett@oracle.com> <20230819004356.1454718-2-Liam.Howlett@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 4E8631C0003 X-Stat-Signature: r6ckkmq55rt763yx1i78o4aqg8zjqtqn X-Rspam-User: X-HE-Tag: 1693327372-178384 X-HE-Meta: U2FsdGVkX19BAhdA27/Af5/fSte8ZANUPJJC67GQcfulfyXJga8WpD08rfUImK80TIuI7SV4YIxw9iXwJbydsKkJjKZqc29jj86hUnApoG+G02QVF6t2l3+nZf6iS7xcSIEr1jFmeDewm4DD/IyoiLhZeiGmlaZcquJFIjQ6Mbb2XcmaQH2slN4+kQPVql7DVpJfdAb0uaDrKYzHnkXvdO29MP6AeuGHF6gujddePHvkm6R4kUtat1nLvKEimmfAEqpIPrlwWEvi80nB+Za/AHSc3YFrNGnvMGQ2K5pGO4olhHTZEbfyCrgXnmnLLsuBNDna5N0svGOtNmJbvyDKBmFlyxWOHKalY9J6BR52pqQP99MEUkIwwcTm2FVM0tdCIxwccfhI15wNztQb4eMfY3odpyBTCoBq0hper8d3nLbpnmIMnAOokVPk/CCrsE6Uooj66pwJU5YHonLjXvY1luB6tCEC94UTj0Z0juCfwwN2faFev16IPsaH/x6t0CXgFVhYFimlUBCutCenhIIYUUXN9Nmb/h925V0JJv1ndL+lCHU2XJrIYE/DoqXVojXepmYPkZtDWka5jqN2CLVkooG9K49eqllL5PPM4yaFgMO0lT3zlZrkg1bF21DEs+jLiii/eLK5xDp/luJMvIyZn758e6ahvAl3YagxiwRXPjcQVKpneLwCOATeAd7VdfeyhkCjYrPRb2SRJxJCBYDe4yPc/tRavF5jWeiXIhkobjReG9bPEAYCLQ2uwkZhBcCPZDhRdJZRl6OCHnJriwyZMpleT+ZkaE1Pl0ElDVOABBCKw4803UNP20fJXnbDgfqc1Rlf6DW07yLy5CvQn0xy73XZrvBqrYWHOhtlrCR7SGlgwUNPuXkec3J27xc/m3d9M2TFP3JC/RSUz5RQXFmXPC3gbooSY0ZIChB8Cjh0wRSFJkVa2ol/JmsUdNOHdGz8titAFzjDRJ78u9Tdfjp CAw3GGW4 nFIt0I67AazJe2FmO4IKkEA+L2qB6AaY+SWiXOX/mr0j4b/OEXdeV31tyJR7P/MlAKZ21hldfz59nQqHhxko2Cd0GyOQ9kESg5JuXnX0ma1XboiBhJDdzk5L6VpGP9fIhDhKOKuu9HU40l3fHXTVYE+64VPF6E0VXcw+ArUz1RHZb6kzt4n0JhmseLrRQAZeq1C3OSIaXS0QSe2d+i3hQdVe6mY8w0LQE3mbaGTwUkQ5HtDq6he2uvzcDalU9KSjwAn/2szSH4kt8RS3C5hCPvYMKIK64ftE/aipUT2qGyKikgqg= 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: 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 +CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0-rza2mevb-10197-g99b80d6b92b5 #237 +Hardware name: Generic R7S9210 (Flattened Device Tree) + unwind_backtrace from show_stack+0x10/0x14 + show_stack from dump_stack_lvl+0x24/0x3c + dump_stack_lvl from __warn+0x74/0xb8 + __warn from warn_slowpath_fmt+0x78/0xb0 + warn_slowpath_fmt from start_kernel+0x2f0/0x480 + start_kernel from 0x0 +---[ end trace 0000000000000000 ]--- Console: colour dummy device 80x30 printk: console [tty0] enabled Calibrating delay loop (skipped) preset value.. 1056.00 BogoMIPS (lpj=5280000) Reverting this commit fixes the issue. RCU-related configs: $ grep RCU .config # RCU Subsystem CONFIG_TINY_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_TINY_SRCU=y # end of RCU Subsystem # RCU Debugging # CONFIG_RCU_SCALE_TEST is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_RCU_REF_SCALE_TEST is not set # CONFIG_RCU_TRACE is not set # CONFIG_RCU_EQS_DEBUG is not set # end of RCU Debugging CONFIG_MAPLE_RCU_DISABLED is not defined (and should BTW be renamed, as CONFIG_* is reserved for kernel configuration options). 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. Do you have a clue? Thanks! > --- a/lib/maple_tree.c > +++ b/lib/maple_tree.c > @@ -4107,6 +4107,10 @@ static inline unsigned char mas_wr_new_end(struct ma_wr_state *wr_mas) > * mas_wr_append: Attempt to append > * @wr_mas: the maple write state > * > + * This is currently unsafe in rcu mode since the end of the node may be cached > + * by readers while the node contents may be updated which could result in > + * inaccurate information. > + * > * Return: True if appended, false otherwise > */ > static inline bool mas_wr_append(struct ma_wr_state *wr_mas, > @@ -4116,6 +4120,9 @@ static inline bool mas_wr_append(struct ma_wr_state *wr_mas, > struct ma_state *mas = wr_mas->mas; > unsigned char node_pivots = mt_pivots[wr_mas->type]; > > + if (mt_in_rcu(mas->tree)) > + return false; > + > if (mas->offset != wr_mas->node_end) > return false; > > -- > 2.39.2 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds