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 D83E6C83F10 for ; Thu, 31 Aug 2023 08:45:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0C50E8E0012; Thu, 31 Aug 2023 04:45:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 076378D0001; Thu, 31 Aug 2023 04:45:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7EBF8E0012; Thu, 31 Aug 2023 04:45:37 -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 D91C88D0001 for ; Thu, 31 Aug 2023 04:45:37 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 9A376A01B0 for ; Thu, 31 Aug 2023 08:45:37 +0000 (UTC) X-FDA: 81183766314.16.5186CA1 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by imf29.hostedemail.com (Postfix) with ESMTP id 085FB120031 for ; Thu, 31 Aug 2023 08:45:34 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=SngwQSSX; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf29.hostedemail.com: domain of zhangpeng.00@bytedance.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=zhangpeng.00@bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693471535; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ZNxZe7wq6zfCLgqQzHCfOQafdDDt4naDzhWZ4W2JCy0=; b=0b/sJQSLTH1b7rKlEoCfWX5ZhTQFDecqhSNNQ8T2MDMpkFvsXDHcCzNSPvz3ucfL4hZn1E QFLmektCTt40MXVaj6FJwSeY0geN+2zy6YE9HMOcao3n1ArUXISGqCkKPjOLi+UFL/PpRI Izq5YMGuafFSHgDHpnD9WCTf+dCqF+Q= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=SngwQSSX; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf29.hostedemail.com: domain of zhangpeng.00@bytedance.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=zhangpeng.00@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693471535; a=rsa-sha256; cv=none; b=vfCXgSQs5A6NiQoUCpiTGTKSd1RMJFihC8tM94Wqboq8lv86otoeRFenGPJPpcRpr1ekQ7 GGRZIXbPtFY0nbubU5begw7BgERiok41PZ99fkeYQQmpLmQEqmA4DsNvdU1ixZPuAIAh73 ydHNIGAosBlwH1yRmkeVbR80ico3/y0= Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-68a56401c12so434942b3a.2 for ; Thu, 31 Aug 2023 01:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1693471533; x=1694076333; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=ZNxZe7wq6zfCLgqQzHCfOQafdDDt4naDzhWZ4W2JCy0=; b=SngwQSSXZLWjtA7UaAJ67jFx8gqtqNIDmAZ0ar9+Ti0RcC7FfpzVfQ6xAlN4UDGH7/ keRVizrY4LwDjXGl/GWnDlcdrMFIraUsZ0U7cKY43igWBE0ndDxvOZK890Ghp79yeix4 qbf06yOWBnOZc5F8zkr/Kd2jV3x9VExIqC6h9sH1JH6aOaaol9mdO+1BTfXZi61CvPzj cFLD5PTpggUGCY7H/q5JIL2fReZERfAqHDRSppi0b+Fko9JwnFm+jlQfafHRFCsFlzia XbPpvjz0ZVy7+lUIyQLEXEy03BzfnzuEDk8ttzOFY1LOkfwHYpmkOvQfjhv7FHQoKqdw Z1Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693471533; x=1694076333; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=ZNxZe7wq6zfCLgqQzHCfOQafdDDt4naDzhWZ4W2JCy0=; b=LcFjq+nd+wlypsExKJC4ZgJYXJjnSxEpVJafDvtjCRU4wbMTwtcZ/BJ1A4OqdTjdyV lI0MZ8hwp+EszheJf1I2NZa781+Jk8DrmPSkwI10nPuIkR8AKTJSFlZE7eXRUddDDvay v+XBMq8QOxMA2NCR666dL1XCBh55LAzoaUM7sK13WRNmhZsXwnrYwiN8p4NAGS+9X0V/ l1wkHMFIUfUlYd4E9CdBLEK5iPFt8hrqOqp2uelBa7p/UoUOCLrJNTLyl5ypp8SiMst4 ZvTH0rGq2Pq39pRhj8aMCrggWFx4LphAB5Fd4qF1TfZSgMwsIP5s0TsLJCk/mRCcS0JP wREw== X-Gm-Message-State: AOJu0YwFdBBAM1xRoX3pgQllUItnWGZPW8JpZHZrSSZ00B3jOx62XhIb s3vg7yjdYElVlLTMxalU7aqQ9w== X-Google-Smtp-Source: AGHT+IHmDx6e4zcXFyVDOOb6K6jjaG05hYVckI6PjHTSQt3YBiSkSKUf78rOgWt26G+FeWf5a+kTUg== X-Received: by 2002:a05:6a00:148f:b0:68b:dd1d:4932 with SMTP id v15-20020a056a00148f00b0068bdd1d4932mr5037278pfu.33.1693471533186; Thu, 31 Aug 2023 01:45:33 -0700 (PDT) Received: from [10.254.254.90] ([139.177.225.231]) by smtp.gmail.com with ESMTPSA id k30-20020a637b5e000000b0056b920051b3sm930402pgn.7.2023.08.31.01.45.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Aug 2023 01:45:32 -0700 (PDT) Message-ID: <6f663185-2ef1-5075-99c9-e16050329d74@bytedance.com> Date: Thu, 31 Aug 2023 16:45:25 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [PATCH v2 1/2] maple_tree: Disable mas_wr_append() when other readers are possible To: Geert Uytterhoeven , Michael Ellerman 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 References: <20230819004356.1454718-1-Liam.Howlett@oracle.com> <20230819004356.1454718-2-Liam.Howlett@oracle.com> <3f86d58e-7f36-c6b4-c43a-2a7bcffd3bd@linux-m68k.org> <87v8cv22jh.fsf@mail.lhotse> From: Peng Zhang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Stat-Signature: ifunn47p3ny51z69beq8ui4p691hur87 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 085FB120031 X-HE-Tag: 1693471534-626899 X-HE-Meta: U2FsdGVkX1/7BNVHRF+WH65wlsB/jKChNwUHksB5Re11wzcRFHNLT67lT5up4aeRF9fdpo1QAURyDumUG6aY92DO07Z3fAeBTeAeYqbuGgO8RA4MM5miP20L2fh8WUbU75SCuU0SFXHgXnsfni89cynZHbGL209lSpQk49TqXmVMO10i24jQcK8qEOQCiqekX9h6NSFP4mFg5xm5R+jg0YhVg2bYa8e72muWG9crhgy5d4meE6f4NDq+7XAkSDgs0wrynJPr78cc1hyLXH/W11XAi0gAWqw8XjyJbNaYdpc9X+LTVWvzo5LPStKXOUP2ke8JCcTxKrUesQLvETV9VSKmhLht7SZJpiBMJlMB23Xa3j9DWvBJL7ZcPZmkvOf5NPac72WfUPmUGzHmsHV+ZjPiK52S5YHuHMlEmxXVdF7BVxucWJTuE/e2MsF6OzSC6XcouHPhqg9GyOIPFipJOW8Ghrn0mrUUee34AC8w1389Mpjt0G11haTgf8UnCBBHR7wfjkiRIN4O3dXdxviN/1W2m+aVrsgh6FqYy0bkZ5fW6q4qSXO333v2fazOllxIJ/A6Fe5TpEHrJ7vbOkDPPSikI/ZeM4vLVu5m+8+ZrmCNYzFUhZAt/UmeK4XnosfsqMit1KHe56H3PD+jkRiw5dx2kwzBOXvmCCSFaogwfth+RUN42MOCW/L83N+SRiPmTyUzg+wVDTJdZIRViGbW4Ntz5Ro8db1dA3qd+mHV/M+ccNAy3mCBZm/KmOT1MI0+uvRymmKMTz59Dq4qnWOVw7CIanwJ8gNxUuBqxQwmgqJWhS1yDl24E/RRvRHpcDLnBd95aACbBy8Y3v4avFMImQmkurPC8y2UBITpEKifOUY5C/h+2dHGZhgIx3FUc0CO3dcksuL0QtHl6GdAJUame/UftlXT6iavazSfM91agvT1k33WpLYaHgJF6/RpyVGIbMwLG8qSVywATyRxb4S cIlC1fUh ml9bVnEomFHlTm8T2EYjZ8D7aJGlbi4BcXj8ScwoSziBlzt+Cqw63fJzPKUDrD1l/aOnfzRzqHC120JcfbZ8AdZ537Wx4UTO6DA313x2U4BZMQmd+RFRQkPD+Bfbqq2KrttoZudbcAVu6jPwiDT1G+reMLYW1xUwd7+KfODXOtCPhpsbhc/F1SIFqeDFLHIohZiyLmH8UPNnvaHgJCAkmrvDf2EiYmIt3wX+ShCrvbUcmyeMkP6ULh9XUE/dB8UeXGHvNZKBOqi8QOHmgUqpV6MnMa74LYpMUdeKr1e4fjXFc5DlZGaS9y+OiIPFCh2tZNtFIUW+0550b9Jp15lUvOf82EdwPBrUZmO0GVRiGzELV/zbV2ixcQUF+QEZu11NVIA70cVYd0Tuz0qSByqM4cf7x4LMUsTsKhYIzRbc66z3oJI58P3K7mWdDNqJzA4xaDL08yDqTJDRCDIVpFDzwy0wC+W4Spm33snKTYuvioZ6NuH1jNy/Wj1ro8iU5YXQJG3VWcJylTBGBJcAM8pKgeNOBgCSGiIsijb3GaK8mv9qb22w= 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: 在 2023/8/31 16:25, Geert Uytterhoeven 写道: > Hi Michael, > > On Thu, Aug 31, 2023 at 7:39 AM Michael Ellerman wrote: >> Geert Uytterhoeven writes: >>> 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. > > Enabling CONFIG_DEBUG_ATOMIC_SLEEP on RZ/A1 and RZ/A2 does > fix the problem. > But there must be more to it, as some of my test configs had it enabled, > and others hadn't, while only RZ/A showed the issue. > I tried disabling it on R-Car M2-W (arm32) and R-Car H3 (arm64), and > that did not cause the problem to happen... I guess this patch triggers a potential problem with the maple tree. I don't have the environment to trigger the problem. Can you apply the following patch to see if the problem still exists? This can help locate the root cause. At least narrow down the scope of the code that has bug. Thanks. diff --git a/lib/maple_tree.c b/lib/maple_tree.c index f723024e1426..1b4b6f6e3095 100644 --- a/lib/maple_tree.c +++ b/lib/maple_tree.c @@ -4351,9 +4351,6 @@ static inline void mas_wr_modify(struct ma_wr_state *wr_mas) if (new_end == wr_mas->node_end && mas_wr_slot_store(wr_mas)) return; - if (mas_wr_node_store(wr_mas, new_end)) - return; - if (mas_is_err(mas)) return; > > Gr{oetje,eeting}s, > > Geert >