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 7B119EDEC53 for ; Wed, 13 Sep 2023 13:15:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BFD8B6B018F; Wed, 13 Sep 2023 09:15:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BAC996B0190; Wed, 13 Sep 2023 09:15:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A74DE6B0191; Wed, 13 Sep 2023 09:15:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 976726B018F for ; Wed, 13 Sep 2023 09:15:13 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6D0C680E40 for ; Wed, 13 Sep 2023 13:15:13 +0000 (UTC) X-FDA: 81231620106.26.4183376 Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) by imf26.hostedemail.com (Postfix) with ESMTP id 7AD2E14000A for ; Wed, 13 Sep 2023 13:15:10 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf26.hostedemail.com: domain of geert.uytterhoeven@gmail.com designates 209.85.128.169 as permitted sender) smtp.mailfrom=geert.uytterhoeven@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694610910; 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; bh=fFiAnOhwKs2lmFqJqrAudE7XU8aOsnd0WSox5jtYe4U=; b=Q5rkske3R48iPzGPrqzgg+8yiQJc+ENF+4ao9IoiOW7dqoLZWf6/SW6LRBSj5u4XNGUmS9 r38rSFUKQSwvffYCWtzNequgFNL6z/o30rmedd/El4NnQV4fAXAmiJadpJLv79kXkyGVck 6KfAnLYfTbW+17DUqp1IUBQ30DlJ8GY= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf26.hostedemail.com: domain of geert.uytterhoeven@gmail.com designates 209.85.128.169 as permitted sender) smtp.mailfrom=geert.uytterhoeven@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694610910; a=rsa-sha256; cv=none; b=UTll6x9EbAkgxKN2nJIhTRDUn9mRrfRpHl6k7KvPAHekh9M0UUdMkVGAtz8Cp4SUI+WmSm PDbL5H47e2VjMDrYTAsqzV30Ioy9aUqT7x641+UA0C0fBkObHQO5sIEv7AN4N6KJJcwTx2 ilS7DvkgzlgUuPi9kQ6JQaPuZggoQ2s= Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-59b8f5b6c0aso31225527b3.0 for ; Wed, 13 Sep 2023 06:15:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694610909; x=1695215709; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fFiAnOhwKs2lmFqJqrAudE7XU8aOsnd0WSox5jtYe4U=; b=iJDi3GnP6CJQdi2mlNI07898N2o9Apz4UC/nix/3N7jcgQugpqe+c07Iq8rH4qD2T2 tkSVonZ6iYkNdMJkXe8+qvkQp3rKGbf59i6/HNpRd/yma1iqq+L7qF+aBjNrs5sp4eAI NKa0E81rz/Y9FlrtzL8I9wijRmwmB0gv5hek7V4GK3IjIwzYG5McHexFepWZdFHxtX7i 9F+dg5H2KtjolV5LN2wbjvleIoAGErua6yLGoSkOiwl7ePf0rz2/B6Xpq8Gew57Kxfy1 Wx80XF4ZIxofxXShz6Rq/wmRYioEIbLE1NPd9S7x6DpcNe4Fy/h9tU4Ca6yGddZcnPXK McOw== X-Gm-Message-State: AOJu0YxwLMWt6FQo3O9F+J/baZdb/dtxyKLE79+UNBZzWGjKL1+DIyHF 5yT2BotTGpS/4krJTLh4i1iaQbRsxvpPNw== X-Google-Smtp-Source: AGHT+IHt0OZFCBUS1Cbju1FYZEtB72rV8tyoD0x/Go0tjAkkY3bNvkTnFQvsp5BBDH22ghmFh+cRzg== X-Received: by 2002:a81:6cca:0:b0:584:4b5f:bac3 with SMTP id h193-20020a816cca000000b005844b5fbac3mr2547107ywc.15.1694610909252; Wed, 13 Sep 2023 06:15:09 -0700 (PDT) Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com. [209.85.219.175]) by smtp.gmail.com with ESMTPSA id v72-20020a81484b000000b0059b085c4051sm3122847ywa.85.2023.09.13.06.15.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Sep 2023 06:15:08 -0700 (PDT) Received: by mail-yb1-f175.google.com with SMTP id 3f1490d57ef6-d8164e661abso466537276.1 for ; Wed, 13 Sep 2023 06:15:08 -0700 (PDT) X-Received: by 2002:a25:2d03:0:b0:d47:d267:26fe with SMTP id t3-20020a252d03000000b00d47d26726femr2582741ybt.21.1694610908416; Wed, 13 Sep 2023 06:15:08 -0700 (PDT) MIME-Version: 1.0 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> <62936d98-6353-486e-8535-86c9f90bc7f4@paulmck-laptop> In-Reply-To: <62936d98-6353-486e-8535-86c9f90bc7f4@paulmck-laptop> From: Geert Uytterhoeven Date: Wed, 13 Sep 2023 15:14:54 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 1/2] maple_tree: Disable mas_wr_append() when other readers are possible To: paulmck@kernel.org 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 7AD2E14000A X-Stat-Signature: 9z9bgjwcy7fcmfthb4qd3jqgfrm69pc9 X-Rspam-User: X-HE-Tag: 1694610910-282549 X-HE-Meta: U2FsdGVkX1+9UaNVfSzq1cmcWBJOsNQNIgzsI7OUCdrJlw/yJOWxYn+9Q76UmGJr4BFFeyWTiFVXWyP7VEA/W151PM9u6Yy7dW8wRBXcRW4WvanZ+Zvtlihbs0NRtaCmlH+T8OiT48qLCdhsG3Igyg4Mmu2/0PfaC2yBOUaDSprmX3BikIESgo56WJ1WCEjit5vkcO9zvxax+taMBKbzquGR9KcvTTuqPdepX8GN6p6kpgqITgoxm3yjIkOQmJo8sjutuLovatRiPBQaYzB7Wmy71+FWHpPBOph5eEzsP/gdn6y1D2Sn7G2p3h53ZkboJ89oyP2lQUHIP6lQ9uey0Xk3vNQXw7oCnE9rOz38oArDYsWqBp9URADAGg5hT1PaKZnVeLoC7pjdbS1970DN9AXaKkbrFmf2EO98rsQEPhRJfVSUPa5RTZfyf5sPBe3ErXiAZsgzEX/XLbrNpsY5P8rbYOitt9aOqSwBsG8B+JIIJC45g8TclUlnunwIaGlXIiNpAM6nmb4+FzFijG8qzlDrPbe8BDmRZc8eOiWdWz7JrajbTb+7byUFed8uGjY6BTjvuO5R6kJ6HQ/8zUkrf+m+yJHjw56YLyT+oPY2nJ+fH4BUEOi3zQ9x2p/zS+J2VD9FmIdNGRzP8+voVv5DruElH32m+KNletpCxcm4o3F7H2VDrA7+ZM9/rK67OmehsrZN7Am3Juwh1liWX1K56FPKoitEbx7J5vWQsf+rngj8X3c8SsWBE+NBpMLsNi7KPW83pQpsmoEpUErzcXE1LxhS8d+RUTYx4Azpf89ObgxNw06FKMEq28nZtmS9cSEUOCtXU36YK21b27rl/lM4Tdetj0huCbQKjwGW9j8JXZrBn43qATCSKnSZp0bLoOeisRm8jwDtrHxaJ5L91y/8vmsG2tHpWRlskaR2PiHD4uVQv9Fk9NQoQQJQQx3rumU5VaIdj0oZy4gbkhOH+27 ZW4WtycW OpN0eDK7MT7763kVGD56KJxQisrjak2pQL5XxdyL0w2dNYAwrEolT3A9S5ROr3NcNhdlMFZFBt5N8a6oPg1dVIJ8jtuSOxJ4UQkIiLFl+FUVTsh5sEuRny8O3ZF5kl8NpegqAkrN3KgNTP1CdQR7GpG3ssVcmmBICH9+xLXsrOqq8phgNklK7WgEHdZOt+40jZy0H6nWQzdKln6ofxR1bs53pePX1BJwH5LAGfepz9Hta1O/MEaQ/iI/RinDuZ34ZGwdPGH4PTaFtjQSka7Rjx+IHPbEhFMPlO5fDHUigzTDTYmKGJ+IlaSi5jrbVk48qPA+RHbY1CuOPfUeJAktPQDGR6ZJ664MVptxofRXBFnICHEj5Px0eWOUnC+1nIXACSZwyGMbFM05Ehk0Rvtc9faHozcwn/B6AkalCePCKbTsNW83O7Pb0rbeFLe6aDB6NuczRyrG+uSPkQhpz1DTGt7iVjWKE6LkQ4Dej/1XPAJnLDa66o1u4d9yAZ9jGO+aKh/p8+FBjKDRwg+tU6hmb8Cs6qo1qhAUtwlG0ldXkOefhil71SR2xoGuoJg== 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 Paul, On Tue, Sep 12, 2023 at 12:00=E2=80=AFPM Paul E. McKenney wrote: > On Tue, Sep 12, 2023 at 10:34:44AM +0200, Geert Uytterhoeven wrote: > > On Tue, Sep 12, 2023 at 10:30=E2=80=AFAM 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=E2=80=AFAM 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 wro= te: > > > > > > > > * 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 fo= r why) > > > > > > > > > > > > > > > > > > > > Apologies on the late response, I was away and have bee= n 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 dupl= icate data and/or > > > > > > > > > > > > incorrect ranges to be returned to a reader during = an update. Although > > > > > > > > > > > > this has not been reported or seen, disable the app= end write operation > > > > > > > > > > > > while the tree is in rcu mode out of an abundance o= f caution. > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > RCU-related configs: > > > > > > > > > > > > > > > > > > > > > > $ grep RCU .config > > > > > > > > > > > # RCU Subsystem > > > > > > > > > > > CONFIG_TINY_RCU=3Dy > > > > > > > > > > I must have been asleep last time I looked at this. I was lookin= g at > > > > > Tree RCU. Please accept my apologies for my lapse. :-/ > > > > > > > > > > However, Tiny RCU's call_rcu() also avoids enabling IRQs, so I wo= uld > > > > > 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_loc= k() > > > > > instead be as follows: > > > > > > > > > > if (!mutex_trylock(&desc->request_mutex)) > > > > > mutex_lock(&desc->request_mutex); > > > > > > > > > > This might fail if __setup_irq() has other dependencies o= n a > > > > > fully operational scheduler. > > > > > > > > > > 2. Move that ppc32 call to __setup_irq() much later, most de= finitely > > > > > after interrupts have been enabled and the scheduler is f= ully > > > > > operational. Invoking mutex_lock() before that time is n= ot 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 hav= e > > > 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! On a typical arm32 system with global or architectured timer, I get: WARNING: CPU: 0 PID: 0 at kernel/irq/manage.c:1587 __setup_irq+0xcc/0x6d0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.6.0-rc1-shmobile-02354-g24e058b77f5a #1655 Hardware name: Generic R-Car Gen2 (Flattened Device Tree) unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x40/0x4c dump_stack_lvl from __warn+0x78/0x10c __warn from warn_slowpath_fmt+0x90/0x11c warn_slowpath_fmt from __setup_irq+0xcc/0x6d0 __setup_irq from __request_percpu_irq+0xb8/0xd0 __request_percpu_irq from set_smp_ipi_range+0x88/0xdc set_smp_ipi_range from gic_of_init+0x1a4/0x4d8 gic_of_init from of_irq_init+0x1f0/0x320 of_irq_init from init_IRQ+0x74/0x104 init_IRQ from start_kernel+0x360/0x5d0 start_kernel from 0x0 Likewise on arm64 with architectured timer. But on these systems I do not see the issue I reported. On RISC-V: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/irq/manage.c:1587 __setup_irq+0x4e6/0x5ee Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc1-02355-g63165363c6a3 #63 Hardware name: Renesas SMARC EVK based on r9a07g043f01 (DT) epc : __setup_irq+0x4e6/0x5ee ra : __setup_irq+0x38/0x5ee epc : ffffffff80049472 ra : ffffffff80048fc4 sp : ffffffff81203cd0 gp : ffffffff812ee760 tp : ffffffff8120d5c0 t0 : ffffffd801854300 t1 : 0000000000000000 t2 : ffffffff81000ad8 s0 : ffffffff81203d20 s1 : ffffffd801855000 a0 : 0000000000000001 a1 : ffffffd801855000 a2 : ffffffd801854280 a3 : 0000000000000001 a4 : 0000000000000000 a5 : 0000000000000000 a6 : ffffffd801852108 a7 : ffffffd801852100 s2 : ffffffd801854280 s3 : 0000000000000005 s4 : ffffffff812c54c0 s5 : 0000000000000005 s6 : ffffffff80dd83a0 s7 : ffffffff805c0cc0 s8 : ffffffd801855018 s9 : 0000000000000000 s10: 0000000000000000 s11: 000000007bf638a0 t3 : 0000000000000000 t4 : 0000000000000002 t5 : ffffffff812882a0 t6 : 0000000000000001 status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [] __setup_irq+0x4e6/0x5ee [] __request_percpu_irq+0x98/0xcc [] riscv_timer_init_dt+0x186/0x22e [] timer_probe+0x62/0xd2 [] time_init+0x86/0xa6 [] start_kernel+0x436/0x618 ---[ end trace 0000000000000000 ]--- Also, no issue here. On the affected systems (RZ/A1 and RZ/A2), the WARN_ON_ONCE() did not trigger, until I applied Liam's patch ("init/main: Clear boot task idle flag"), which got rid of the "Interrupts were enabled early" warning, and now tells me, as expected: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/irq/manage.c:1587 __setup_irq+0xc8/0x654 CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc1-rskrza1-02357-g237e09fd64b8-dirty #829 Hardware name: Generic R7S72100 (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 __setup_irq+0xc8/0x654 __setup_irq from request_threaded_irq+0xac/0x13c request_threaded_irq from timer_of_init+0x238/0x2c8 timer_of_init from ostm_init+0x98/0x208 ostm_init from timer_probe+0x90/0xe4 timer_probe from start_kernel+0x2c0/0x488 start_kernel from 0x0 ---[ end trace 0000000000000000 ]--- However, Liam's patch causes lots of warnings on the other systems... > > > > Note that there are (possibly different) issues seen on ppc32 and o= n arm32 > > > > (Renesas RZ/A in particular, but not on other Renesas ARM systems). > > > > > > > > I saw an issue on arm32 with cfeb6ae8bcb96ccf, but not with cfeb6ae= 8bcb96ccf^. > > > > 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-m= 68k.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(). With the WARN_ON_ONCE() moved from __setup_irq() to mutex_lock(), it does trigger on RZ/A1: Dentry cache hash table entries: 4096 (order: 2, 16384 bytes, linear) Inode-cache hash table entries: 2048 (order: 1, 8192 bytes, linear) Built 1 zonelists, mobility grouping off. Total pages: 8128 +------------[ cut here ]------------ +WARNING: CPU: 0 PID: 0 at kernel/locking/mutex.c:283 mutex_lock+0x3c/0x68 +CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc1-rskrza1-02360-gd762084b1737-dirty #831 +Hardware name: Generic R7S72100 (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 mutex_lock+0x3c/0x68 + mutex_lock from __cpuhp_setup_state_cpuslocked+0x44/0x1c0 + __cpuhp_setup_state_cpuslocked from page_alloc_init_cpuhp+0x28/0x64 + page_alloc_init_cpuhp from mm_core_init+0x18/0x2a4 + mm_core_init from start_kernel+0x250/0x47c + start_kernel from 0x0 +---[ end trace 0000000000000000 ]--- mem auto-init: stack:off, heap alloc:off, heap free:off Memory: 22876K/32768K available (5120K kernel code, 951K rwdata, 1208K rodata, 1024K init, 321K bss, 9892K reserved, 0K cma-reserved) SLUB: HWalign=3D64, Order=3D0-1, MinObjects=3D0, CPUs=3D1, Nodes=3D1 Thanks! Gr{oetje,eeting}s, Geert --=20 Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k= .org In personal conversations with technical people, I call myself a hacker. Bu= t when I'm talking to journalists I just say "programmer" or something like t= hat. -- Linus Torvalds