lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAOe6JY2_E7FCAHkLJpG5BF9xvMiH4=MDmEkFzJOcViKBWBF6kw@mail.gmail.com> Date: Thu, 23 Feb 2012 22:29:31 +0800 From: Tao Jiang <jiangtao.jit@...il.com> To: Hillf Danton <dhillf@...il.com> Cc: Brian Gerst <brgerst@...il.com>, Cong Wang <xiyou.wangcong@...il.com>, linux-kernel@...r.kernel.org Subject: Re: A problem with percpu variable cpu_number Hillf Danton: Thanks for your remind and sorry for my poor English. 2012/2/22 Hillf Danton <dhillf@...il.com>: > On Wed, Feb 22, 2012 at 7:13 PM, Tao Jiang <jiangtao.jit@...il.com> 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 <brgerst@...il.com>: >>> On Tue, Feb 21, 2012 at 9:29 AM, Cong Wang <xiyou.wangcong@...il.com> 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 <cpu_number>: >>> >>> 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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists