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 X-Spam-Level: X-Spam-Status: No, score=-6.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0C279C47095 for ; Tue, 6 Oct 2020 17:56:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AFCD2206F7 for ; Tue, 6 Oct 2020 17:56:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602007015; bh=6xwkV5dowZG+AGFK3o6Fg/zFGiBS1Zab6Mdlj9bmdf8=; h=Date:From:To:cc:Subject:In-Reply-To:References:List-ID:From; b=tQyWTkVLByKjenICayOU1uKTAKRIz+qzOQ8WF2JtcFHKOpcRQnFGkOtzr47zgIHQH x54NoqgA//jgL7wQppzHGX2atvr1ZQGE5/B4IFLQt64eWfZgxstOWa69+N3F8p76o8 FsDtBEi7Rto3BS4KDRqU1E2FB1CR5EZaUKfYBYMY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726695AbgJFR4y (ORCPT ); Tue, 6 Oct 2020 13:56:54 -0400 Received: from mail.kernel.org ([198.145.29.99]:43298 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725925AbgJFR4y (ORCPT ); Tue, 6 Oct 2020 13:56:54 -0400 Received: from sstabellini-ThinkPad-T480s (c-24-130-65-46.hsd1.ca.comcast.net [24.130.65.46]) (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 ECA64206D4; Tue, 6 Oct 2020 17:56:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602007013; bh=6xwkV5dowZG+AGFK3o6Fg/zFGiBS1Zab6Mdlj9bmdf8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=p/o8rpkPaWKAOJErXCTTnFk86VLXwqH9uU7bgiHZrpS2zPwxMKi9yqd0krYwsViDK mZ0wW7xCx8VizqKhE0K8vAJ+jisxAt+oOURnRiiLIw1gUSJsFiL9w30iWr88TAOows jAoRglv7lDrdcz7rt2IuDEdDREj9qLyTU1PA5sZo= Date: Tue, 6 Oct 2020 10:56:52 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Masami Hiramatsu cc: Stefano Stabellini , Julien Grall , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, =?UTF-8?Q?Alex_Benn=C3=A9e?= , takahiro.akashi@linaro.org, jgross@suse.com, boris.ostrovsky@oracle.com Subject: Re: [PATCH] arm/arm64: xen: Fix to convert percpu address to gfn correctly In-Reply-To: <20201006114058.b93839b1b8f35a470874572b@kernel.org> Message-ID: References: <160190516028.40160.9733543991325671759.stgit@devnote2> <20201006114058.b93839b1b8f35a470874572b@kernel.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 6 Oct 2020, Masami Hiramatsu wrote: > On Mon, 5 Oct 2020 18:13:22 -0700 (PDT) > Stefano Stabellini wrote: > > > On Mon, 5 Oct 2020, Julien Grall wrote: > > > Hi Masami, > > > > > > On 05/10/2020 14:39, Masami Hiramatsu wrote: > > > > Use per_cpu_ptr_to_phys() instead of virt_to_phys() for per-cpu > > > > address conversion. > > > > > > > > In xen_starting_cpu(), per-cpu xen_vcpu_info address is converted > > > > to gfn by virt_to_gfn() macro. However, since the virt_to_gfn(v) > > > > assumes the given virtual address is in contiguous kernel memory > > > > area, it can not convert the per-cpu memory if it is allocated on > > > > vmalloc area (depends on CONFIG_SMP). > > > > > > Are you sure about this? I have a .config with CONFIG_SMP=y where the per-cpu > > > region for CPU0 is allocated outside of vmalloc area. > > > > > > However, I was able to trigger the bug as soon as CONFIG_NUMA_BALANCING was > > > enabled. > > > > I cannot reproduce the issue with defconfig, but I can with Masami's > > kconfig. > > > > If I disable just CONFIG_NUMA_BALANCING from Masami's kconfig, the > > problem still appears. > > > > If I disable CONFIG_NUMA from Masami's kconfig, it works, which is > > strange because CONFIG_NUMA is enabled in defconfig, and defconfig > > works. > > Hmm, strange, because when I disabled CONFIG_NUMA_BALANCING, the issue > disappeared. > > --- config-5.9.0-rc4+ 2020-10-06 11:36:20.620107129 +0900 > +++ config-5.9.0-rc4+.buggy 2020-10-05 21:04:40.369936461 +0900 > @@ -131,7 +131,8 @@ > CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y > CONFIG_CC_HAS_INT128=y > CONFIG_ARCH_SUPPORTS_INT128=y > -# CONFIG_NUMA_BALANCING is not set > +CONFIG_NUMA_BALANCING=y > +CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y > CONFIG_CGROUPS=y > CONFIG_PAGE_COUNTER=y > CONFIG_MEMCG=y > > So buggy config just enabled NUMA_BALANCING (and default enabled) Yeah but both NUMA and NUMA_BALANCING are enabled in defconfig which works fine... [...] > > The fix is fine for me. I tested it and it works. We need to remove the > > "Fixes:" line from the commit message. Ideally, replacing it with a > > reference to what is the source of the problem. > > OK, as I said, it seems commit 9a9ab3cc00dc ("xen/arm: SMP support") has > introduced the per-cpu code. So note it instead of Fixes tag. ...and commit 9a9ab3cc00dc was already present in 5.8 which also works fine with your kconfig. Something else changed in 5.9 causing this breakage as a side effect. Commit 9a9ab3cc00dc is there since 2013, I think it is OK -- this patch is fixing something else.