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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4973EE03.2060106@kernel.org>
Date:	Mon, 19 Jan 2009 12:05:39 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Brian Gerst <brgerst@...il.com>
CC:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] x86-64: Remove the PDA

Hello, Brian.

Brian Gerst wrote:
>> As discussed before, the above chunks do drop one #ifdef CONFIG_SMP
>> but it does add a obscure relocation and please note that it's
>> different from early_gdt_descr.  early_gdt_descr is needed to bring up
>> the cpu so there's no other way to do it but to relocate it in
>> assembly.  If you absolutely have to relocate irq_stack_ptr early,
>> please do it in C code in head64.c but then again irq_stack_ptr is not
>> even necessary till traps_init() which is way after per cpu area
>> setup.  So, the above two chunks are not necessary && even if they go
>> in, they don't have much to do with this patch.
> 
> I'll give you that this particular variable doesn't need early
> adjustment currently.  I'd prefer if you left the ifdef off the first
> hunk, though.  A comment will suffice to document that the initial
> value is going to be overwritten later on SMP.

Yeah, maybe.  I don't know.  If we ever get to a point where we can
fully initialize per cpu area for cpu0, things like this can probably
go away, but for now, I just thought it would be better to make it
clear that UP and SMP are taking different initialization paths &&
that was how the code looked like before this patch, so...  But no big
deal one way or another, right?

Thanks.

-- 
tejun
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ