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 98071C433EF for ; Thu, 9 Jun 2022 10:12:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AC8BE6B009B; Thu, 9 Jun 2022 06:12:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A85DA6B009D; Thu, 9 Jun 2022 06:12:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 941EB8D0001; Thu, 9 Jun 2022 06:12:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 845196B009B for ; Thu, 9 Jun 2022 06:12:05 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 540E320747 for ; Thu, 9 Jun 2022 10:12:05 +0000 (UTC) X-FDA: 79558281810.30.3B8B5E4 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf08.hostedemail.com (Postfix) with ESMTP id 9F062160068 for ; Thu, 9 Jun 2022 10:12:04 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id AB922B82CED; Thu, 9 Jun 2022 10:12:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18FBCC34114; Thu, 9 Jun 2022 10:11:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654769521; bh=IVNlOmdDGOUhLFAR3nMIzH30XrHdkBsJEHd4SHkHy+g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HhlUSxnfqr0u9JH7JbuMdZrEG4QsD6BUNaeNixZyQEzJMe3i1KaBrT7YovYLrYDju di83tadCSFZwPXQnB1q+h4vGM2TctQ76ZM1gThy3w8+A1eETccBhkl3Af2POKnmP5P CoO7tIs9BK7N7pbqYiJJGb8gQDM1z9MhHFjslQeRB/i6bGJGlc9bZo1cBq3nyhWw8C bQHBnxH43LxJxyqcrwxEwdhYUUtDorw984yXTKhlWXckHpAfu4fnj7uH0/+GzPw8Sv 2DG1VZ7HJQRYdD/3nCg6gFN9LkpGguOFjg43y0muhNrCXZ9GloCwq44NNlAcsQcAN/ Foiy1l4SyhOmA== Date: Thu, 9 Jun 2022 11:11:54 +0100 From: Will Deacon To: Kefeng Wang Cc: Vasily Averin , Naresh Kamboju , Shakeel Butt , Linux ARM , Stephen Rothwell , Linux-Next Mailing List , open list , regressions@lists.linux.dev, lkft-triage@lists.linaro.org, linux-mm , Andrew Morton , Ard Biesheuvel , Arnd Bergmann , Catalin Marinas , Raghuram Thammiraju , Mark Brown , Roman Gushchin , Qian Cai Subject: Re: [next] arm64: boot failed - next-20220606 Message-ID: <20220609101153.GB2187@willie-the-truck> References: <20220607162504.7fd5a92a@canb.auug.org.au> <2a4cc632-c936-1e42-4fdc-572334c58ee1@openvz.org> <44530040-0384-796e-143f-b7293886753c@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <44530040-0384-796e-143f-b7293886753c@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1654769525; a=rsa-sha256; cv=none; b=YDaqlXm6WxEpN0EowkHQiDjqs1vhKlWRrZUXhNUVcbGQMjZBBPqhPBU4Uu6NVMrgH30Kds yerjNQTSry75IuD/CYrHQJOwgzGjBs9qngFnBnyM5fq16UxmBZg2fs2OIP8K8ZO3b5cSlW B8WRVVpdglxEYp+OOAt0JGHhOZSHoeI= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HhlUSxnf; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of will@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=will@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1654769525; 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=Np7YrPcfLeFAKnwmz1CrcZRCc5QB3obYyAGTIJ556jA=; b=S5NKbbpMeavDzlToIcR25eltca/a6oNe++gv/+LL0q7MuJSzRz2bXWT7vCQIlFEDfibkPT 0a2iD1aWzUGFEQVwSh8+xMr9zhRseDBlNL2UJVvye24iLTgls8fht1AUxXml/fYfq5pdeV t16+H5l9zvjurvcnHf8CRczvRkoK1bs= X-Stat-Signature: kmeeng4hbf9jj66soithp7rnhdmn98i5 X-Rspamd-Queue-Id: 9F062160068 X-Rspam-User: X-Rspamd-Server: rspam10 Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HhlUSxnf; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of will@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=will@kernel.org X-HE-Tag: 1654769524-392161 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: On Thu, Jun 09, 2022 at 11:44:09AM +0800, Kefeng Wang wrote: > On 2022/6/9 10:49, Vasily Averin wrote: > > mem_cgroup_from_obj(): > > ffff80000836cf40: d503245f bti c > > ffff80000836cf44: d503201f nop > > ffff80000836cf48: d503201f nop > > ffff80000836cf4c: d503233f paciasp > > ffff80000836cf50: d503201f nop > > ffff80000836cf54: d2e00021 mov x1, #0x1000000000000 // #281474976710656 > > ffff80000836cf58: 8b010001 add x1, x0, x1 > > ffff80000836cf5c: b25657e4 mov x4, #0xfffffc0000000000 // #-4398046511104 > > ffff80000836cf60: d34cfc21 lsr x1, x1, #12 > > ffff80000836cf64: d37ae421 lsl x1, x1, #6 > > ffff80000836cf68: 8b040022 add x2, x1, x4 > > ffff80000836cf6c: f9400443 ldr x3, [x2, #8] > > > > x5 : ffff80000a96f000 x4 : fffffc0000000000 x3 : ffff80000ad5e680 > > x2 : fffffe00002bc240 x1 : 00000200002bc240 x0 : ffff80000af09740 > > > > x0 = 0xffff80000af09740 is an argument of mem_cgroup_from_obj() > > according to System.map it is init_net > > > > This issue is caused by calling virt_to_page() on address of static variable init_net. > > Arm64 consider that addresses of static variables are not valid virtual addresses. > > On x86_64 the same API works without any problem. This just depends on whether or not the kernel is running out of the linear mapping or not. On arm64, we use the vmalloc area for the kernel image and so virt_to_page() won't work, just like it won't work for modules on other architectures. How are module addresses handled by mem_cgroup_from_obj()? > > Unfortunately I do not understand the cause of the problem. > > I do not see any bugs in my patch. > > I'm using an existing API, mem_cgroup_from_obj(), to find the memory cgroup used > > to account for the specified object. > > In particular, in the current case, I wanted to get the memory cgroup of the > > specified network namespace by the name taken from for_each_net(). > > The first object in this list is the static structure unit_net > > root@test:~# cat /proc/kallsyms |grep -w _data > ffff80000a110000 D _data > root@test:~# cat /proc/kallsyms |grep -w _end > ffff80000a500000 B _end > root@test:~# cat /proc/kallsyms |grep -w init_net > ffff80000a4eb980 B init_net > > the init_net is located in data section, on arm64, it is allowed by vmalloc, > see > >     map_kernel_segment(pgdp, _data, _end, PAGE_KERNEL, &vmlinux_data, 0, 0); > > and the arm has same behavior. > > We could let init_net be allocated dynamically, but I think it could change > a lot. > > Any better sugguestion, Catalin? For this specific issue, can you use lm_alias to get a virtual address suitable for virt_to_page()? My question about modules still applies though. Will