Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752374Ab2BVNVL (ORCPT ); Wed, 22 Feb 2012 08:21:11 -0500 Received: from mail-vw0-f46.google.com ([209.85.212.46]:46894 "EHLO mail-vw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751565Ab2BVNVH convert rfc822-to-8bit (ORCPT ); Wed, 22 Feb 2012 08:21:07 -0500 Authentication-Results: mr.google.com; spf=pass (google.com: domain of dhillf@gmail.com designates 10.52.26.65 as permitted sender) smtp.mail=dhillf@gmail.com; dkim=pass header.i=dhillf@gmail.com MIME-Version: 1.0 In-Reply-To: References: <4F411373.50304@gmail.com> Date: Wed, 22 Feb 2012 21:21:06 +0800 Message-ID: Subject: Re: A problem with percpu variable cpu_number From: Hillf Danton To: Tao Jiang Cc: Brian Gerst , Cong Wang , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2567 Lines: 67 On Wed, Feb 22, 2012 at 7:13 PM, Tao Jiang wrote: > Hi: > > Thank you all. > > So in boot_cpu_init(), it will always set bit 0 to these masks. > If the boot cpu is the first processor, it's the right case. > And if the BP is not the first one, is it wrong? > But can it happen that the BP is not cpu0? BP could be not "the first one". Due to that current code boots fine, I guess, you mess logic CPU with hard CPU. btw, replying messages in this way looks not fine. > Thank you. > > > 2012/2/22 Brian Gerst : >> On Tue, Feb 21, 2012 at 9:29 AM, Cong Wang wrote: >>> On 02/21/2012 08:41 PM, Tao Jiang wrote: >>>> >>>> Hi Cong Wang: >>>> >>>> I read the file vmlinux.lds.S in arch/x86/kernel >>>> section .data..percpu is between .init.data and .init.end >>>> Is that means these percpu variables will be freed after init? >>> >>> >>> % grep -e __init_begin -e __init_end -e __per_cpu_start -e __per_cpu_end >>> /boot/System.map >>> 0000000000000000 D __per_cpu_start >>> 0000000000014bc0 D __per_cpu_end >>> ffffffff81cf3000 D __init_begin >>> ffffffff81dfc000 R __init_end >>> % objdump -d -j .data..percpu vmlinux | grep cpu_number >>> 000000000000dc38 : >> >> The .data..percpu section is placed in the init section, but x86-64 is >> a special case as noted below.  The boot cpu is pointed to the init >> percpu section until setup_per_cpu_areas() is called, when it switches >> to the regular percpu area.  The init percpu data is then freed with >> all other init data. >> >> The reason the percpu symbols start at virtual address 0 on x86-64 is >> because of the requirement that gs_base must be a canonical address >> (it cannot be a simple offset like x86-32).  But, the data is still >> loaded in the init section in memory.  See >> arch/x86/kernel/vmlinux.lds.S for the explanation of how the linker >> changes the program headers to set the virtual address to zero but >> keeps the load address in the init section. >> >> To answer the original question. in the case of cpu_number, it is set >> to zero in the init section because it doesn't have an explicit >> initializer.  Therefore the boot cpu will always read zero for the >> cpu_number, even before setup_per_cpu_areas() is called. >> >> >> -- >> Brian Gerst > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/