From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B9B8F210B for ; Thu, 9 Jun 2022 10:12:01 +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> Precedence: bulk X-Mailing-List: regressions@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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) 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 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4CADAC433EF for ; Thu, 9 Jun 2022 10:13:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=R8lve0xrQDwL4esZhE6b4bf2pAQfbo+Hm94g0UDwQuQ=; b=NoluSppV9J/fbF GmGl31s0SSM1+gZvG0OLtsvZCiIVtBBX9Caumkljnr+E9ax+2HStzg4kq50fHZ4YCsSKMd2+fg03z w0rwIIVe12PXgyBLCUmunA8wSUt3A8wLrh5qhjKs2v6qLKvvGUrjvDV7GMIfelsQfW/fOp6LF+WZk Qvv3qfMvu3Wt67ieOL5K1FaQrN3v97oy+u8FdsdLUyAaLbCEMyvCcZZM6zO3HJgMgHDKCEJS2hL8T ay2arIoB0WPkuHM8Rk3yJ7fo0lbkkUjYQjMG6+INa3tsCBFD44/vugKu7pnbsN1+JLzeggVr+upPR 0mfos01BzJz7x1cL0zyw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nzF97-000u8C-Li; Thu, 09 Jun 2022 10:12:10 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nzF92-000u4v-4l for linux-arm-kernel@lists.infradead.org; Thu, 09 Jun 2022 10:12:05 +0000 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-Disposition: inline In-Reply-To: <44530040-0384-796e-143f-b7293886753c@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220609_031204_519450_2278267E X-CRM114-Status: GOOD ( 26.11 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 =3D 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 var= iable 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 cg= roup used > > to account for the specified object. > > In particular, in the current case, I wanted to get the memory cgroup o= f 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 vmall= oc, > see > = > =A0=A0=A0 map_kernel_segment(pgdp, _data, _end, PAGE_KERNEL, &vmlinux_dat= a, 0, 0); > = > and the arm has same behavior. > = > We could let init_net be allocated dynamically, but I think it could chan= ge > 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel