Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754722AbYGIUGC (ORCPT ); Wed, 9 Jul 2008 16:06:02 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753324AbYGIUFv (ORCPT ); Wed, 9 Jul 2008 16:05:51 -0400 Received: from gw.goop.org ([64.81.55.164]:54546 "EHLO mail.goop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752855AbYGIUFu (ORCPT ); Wed, 9 Jul 2008 16:05:50 -0400 Message-ID: <48751A0D.5020107@goop.org> Date: Wed, 09 Jul 2008 13:05:33 -0700 From: Jeremy Fitzhardinge User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: "Eric W. Biederman" CC: Mike Travis , Ingo Molnar , Andrew Morton , "H. Peter Anvin" , Christoph Lameter , Jack Steiner , linux-kernel@vger.kernel.org Subject: Re: [RFC 00/15] x86_64: Optimize percpu accesses References: <20080709165129.292635000@polaris-admin.engr.sgi.com> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1467 Lines: 37 Eric W. Biederman wrote: > I just took a quick look at how stack_protector works on x86_64. Unless there is > some deep kernel magic that changes the segment register to %gs from the ABI specified > %fs CC_STACKPROTECTOR is totally broken on x86_64. We access our pda through %gs. > -mcmodel=kernel switches it to using %gs. > Further -fstack-protector-all only seems to detect against buffer overflows and > thus corruption of the stack. Not stack overflows. So it doesn't appear especially > useful. > It's a bit useful. But at the cost of preventing a pile of more useful unification work, not to mention making all access to per-cpu variables more expensive. > So we don't we kill the broken CONFIG_CC_STACKPROTECTOR. Stop trying to figure out > how to use a zero based percpu area. > Yes, please. > That should allow us to make the current pda a per cpu variable, and use %gs with > a large offset to access the per cpu area. And since it is only the per cpu accesses > and the pda accesses that will change we should not need to fight toolchain issues > and other weirdness. The linked binary can remain the same. > Yes, and it would be functionally identical to the 32-bit code. J -- 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/