Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp13843ybm; Tue, 26 May 2020 09:34:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyFLh21LFYULnxApBX4xf62IWZrMmyN/OG4DTfQeiT37/g0MpeT2V+O1C5mw/qNztGFLbD2 X-Received: by 2002:a50:abe3:: with SMTP id u90mr20827000edc.278.1590510854089; Tue, 26 May 2020 09:34:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590510854; cv=none; d=google.com; s=arc-20160816; b=IPCUTtkKdM6hCVG4loCD7EgM0X45mCciaaR3/w/wRdzuJtGG6+4bOStYuOx3lI0Op1 siw0eDM0DbAubmdzl1e7y8wYbT7F05QjGNUPfaPw6QwvQ4/UepHpeWbdq4v9XtAi94+Z jBXKQ/WlHs5DWv0kKf3n1fU6vlHZyVAh+AcyaORyzkGW1LnB6mWeRH5iDTR4Tx/PWaaq Nmi0lENzpb/mRog8L5rK/FmONMouHhMzLcSc63FLO4cdLD735ghyRC7YDQxgdZc9F9X7 b28a3IxRudpmPYubrOOqEeS6Q0zFEmEEIkFLVA5k9vM/cBzDXa2U1xsVIQoTSuxUFPvr Uhgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=pdLR7T/tuLKjSjJGveG3lZgBr12OswxcBEwNN0WAkOo=; b=kL97cL1VazXZ/KC9N7qGHfOOE6TYTj6FHVfxDyFDet78vuuGjMeWV/mCpPwOHZpvXf drBIttXr9afTovnJv/SqfROalvSJ7tMcKeC0iRsS2uVf259OL5HDxuJ2t1pM1q+YHhPu DK3PF2hpc5j3bMw2en/w65SAw+M5w2SFNy1TIHrpOpnAi9bG1AILosbdoH11CU1Z5QYv 0i0n6iVH5q9iCF5/KEJHBLUWmxwC1bldgMjLGxEbjOpFi3b76COn/a0BHSIC5j+xi8jH kOm3GbqqSpBvGBxDC3gf9EhRiFV/P14oOf6ARzdIccUBPWRiLstJWXzaZ9JVNrDp7yQm esnw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Tlu+kUsA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j93si193308edb.331.2020.05.26.09.33.49; Tue, 26 May 2020 09:34:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Tlu+kUsA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729718AbgEZQ3a (ORCPT + 99 others); Tue, 26 May 2020 12:29:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:53414 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729597AbgEZQ33 (ORCPT ); Tue, 26 May 2020 12:29:29 -0400 Received: from kernel.org (unknown [87.70.212.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6DB1D20776; Tue, 26 May 2020 16:29:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590510568; bh=TbUUgIF6mgLobEp3W6dqdV0WdKcIkW1P4WlfGLG2wJg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Tlu+kUsAUHzzEGHCVBe6r8A+U9cPi/d8OuzGyVspXJH0jMRUeivnTXQ0ZBENZPmUW pvLMvN6Su85rkTax3cDwabYfDCrP+20ybkW2VI4EozEsmdsxqfzyn3Us0/tqnBvV3n KnSEio6fJUe4j9II+vin40X91uV/gwqmPd6WS0ts= Date: Tue, 26 May 2020 19:29:21 +0300 From: Mike Rapoport To: Guenter Roeck Cc: Will Deacon , linux-kernel@vger.kernel.org, elver@google.com, tglx@linutronix.de, paulmck@kernel.org, mingo@kernel.org, peterz@infradead.org, "David S. Miller" Subject: Re: [PATCH v5 04/18] sparc32: mm: Reduce allocation size for PMD and PTE tables Message-ID: <20200526162921.GE48741@kernel.org> References: <20200517000750.GA157503@roeck-us.net> <20200518083715.GA31383@willie-the-truck> <20200520170306.GG1118872@kernel.org> <6034a1b5-d4f6-c836-142c-9b3b06db3246@roeck-us.net> <20200520195110.GH1118872@kernel.org> <20200524123256.GN1118872@kernel.org> <20200526132634.GC27166@willie-the-truck> <20200526140126.GD27166@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 26, 2020 at 09:18:54AM -0700, Guenter Roeck wrote: > On 5/26/20 7:01 AM, Will Deacon wrote: > > On Tue, May 26, 2020 at 02:26:35PM +0100, Will Deacon wrote: > >> On Sun, May 24, 2020 at 03:32:56PM +0300, Mike Rapoport wrote: > >>> On Thu, May 21, 2020 at 04:02:11PM -0700, Guenter Roeck wrote: > >>>> On 5/20/20 12:51 PM, Mike Rapoport wrote: > >>>>> On Wed, May 20, 2020 at 12:03:31PM -0700, Guenter Roeck wrote: > >>>>>> With above patch applied on top of Ira's patch, I get: > >>>>>> > >>>>>> BUG: spinlock recursion on CPU#0, S01syslogd/139 > >>>>>> lock: 0xf5448350, .magic: dead4ead, .owner: S01syslogd/139, .owner_cpu: 0 > >>>>>> CPU: 0 PID: 139 Comm: S01syslogd Not tainted 5.7.0-rc6-next-20200518-00002-gb178d2d56f29-dirty #1 > >>>>>> [f0067a64 : > >>>>>> do_raw_spin_lock+0xa8/0xd8 ] > >>>>>> [f00d5034 : > >>>>>> copy_page_range+0x328/0x804 ] > >>>>>> [f0025be4 : > >>>>>> dup_mm+0x334/0x434 ] > >>>>>> [f0027124 : > >>>>>> copy_process+0x1224/0x12b0 ] > >>>>>> [f0027344 : > >>>>>> _do_fork+0x54/0x30c ] > >>>>>> [f0027670 : > >>>>>> do_fork+0x5c/0x6c ] > >>>>>> [f000de44 : > >>>>>> sparc_do_fork+0x18/0x38 ] > >>>>>> [f000b7f4 : > >>>>>> do_syscall+0x34/0x40 ] > >>>>>> [5010cd4c : > >>>>>> 0x5010cd4c ] > >>>>>> > >>>>>> Looks like yet another problem. > >>>>> > >>>>> I've checked the patch above on top of the mmots which already has Ira's > >>>>> patches and it booted fine. I've used sparc32_defconfig to build the > >>>>> kernel and qemu-system-sparc with default machine and CPU. > >>>>> > >>>> > >>>> Try sparc32_defconfig+SMP. > >>> > >>> I see a differernt problem, but this could be related: > >>> > >>> INIT: version 2.86 booting > >>> rcu: INFO: rcu_sched detected stalls on CPUs/tasks: > >>> (detected by 0, t=5252 jiffies, g=-935, q=3) > >>> rcu: All QSes seen, last rcu_sched kthread activity 5252 (-68674--73926), jiffies_till_next_fqs=1, root ->qsmask 0x0 > >>> rcu: rcu_sched kthread starved for 5252 jiffies! g-935 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 > >>> rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior. > >>> rcu: RCU grace-period kthread stack dump: > >>> rcu_sched R running task 0 10 2 0x00000000 > >>> > >>> I'm running a bit old debian [1] with qemu-img-sparc. > >>> > >>> My bisect pointed at commit 8c8f3156dd40 ("sparc32: mm: Reduce > >>> allocation size for PMD and PTE tables"). The commit ID is valid for > >>> next-20200522. > >> > >> Can you try the diff below please? > > > > Actually, that's racy. New version below! > > > > Applied on top of next-20200526, with defconfig+SMP, I still get: > > BUG: Bad page state in process swapper/0 pfn:0069f > > many times. Did I have to revert something else ? Sorry, I lost track. The bad page messages are fixed by [1], but this is not in mmotm or linux-next. This is not related to SMP hangs. [1] https://lore.kernel.org/lkml/20200524165358.27188-1-rppt@kernel.org/ > Note that "-smp 2" on SS-10 works for me (with the same page state > messages). > > Guenter > > > > Will > > > > --->8 > > > > diff --git a/arch/sparc/mm/srmmu.c b/arch/sparc/mm/srmmu.c > > index c861c0f0df73..068029471aa4 100644 > > --- a/arch/sparc/mm/srmmu.c > > +++ b/arch/sparc/mm/srmmu.c > > @@ -363,11 +363,16 @@ pgtable_t pte_alloc_one(struct mm_struct *mm) > > > > if ((ptep = pte_alloc_one_kernel(mm)) == 0) > > return NULL; > > + > > page = pfn_to_page(__nocache_pa((unsigned long)ptep) >> PAGE_SHIFT); > > - if (!pgtable_pte_page_ctor(page)) { > > - __free_page(page); > > - return NULL; > > + > > + spin_lock(&mm->page_table_lock); > > + if (page_ref_inc_return(page) == 2 && !pgtable_pte_page_ctor(page)) { > > + page_ref_dec(page); > > + ptep = NULL; > > } > > + spin_unlock(&mm->page_table_lock); > > + > > return ptep; > > } > > > > @@ -376,7 +381,12 @@ void pte_free(struct mm_struct *mm, pgtable_t ptep) > > struct page *page; > > > > page = pfn_to_page(__nocache_pa((unsigned long)ptep) >> PAGE_SHIFT); > > - pgtable_pte_page_dtor(page); > > + > > + spin_lock(&mm->page_table_lock); > > + if (page_ref_dec_return(page) == 1) > > + pgtable_pte_page_dtor(page); > > + spin_unlock(&mm->page_table_lock); > > + > > srmmu_free_nocache(ptep, SRMMU_PTE_TABLE_SIZE); > > } > > > > diff --git a/mm/Kconfig b/mm/Kconfig > > index c1acc34c1c35..97458119cce8 100644 > > --- a/mm/Kconfig > > +++ b/mm/Kconfig > > @@ -192,6 +192,9 @@ config MEMORY_HOTREMOVE > > # Default to 4 for wider testing, though 8 might be more appropriate. > > # ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock. > > # PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes. > > +# SPARC32 allocates multiple pte tables within a single page, and therefore > > +# a per-page lock leads to problems when multiple tables need to be locked > > +# at the same time (e.g. copy_page_range()). > > # DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC spinlock_t also enlarge struct page. > > # > > config SPLIT_PTLOCK_CPUS > > @@ -199,6 +202,7 @@ config SPLIT_PTLOCK_CPUS > > default "999999" if !MMU > > default "999999" if ARM && !CPU_CACHE_VIPT > > default "999999" if PARISC && !PA20 > > + default "999999" if SPARC32 > > default "4" > > > > config ARCH_ENABLE_SPLIT_PMD_PTLOCK > > > -- Sincerely yours, Mike.