Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752701Ab3IVElO (ORCPT ); Sun, 22 Sep 2013 00:41:14 -0400 Received: from gate.crashing.org ([63.228.1.57]:56259 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752306Ab3IVElM (ORCPT ); Sun, 22 Sep 2013 00:41:12 -0400 Message-ID: <1379824754.24090.11.camel@pasglop> Subject: Re: [RFC GIT PULL] softirq: Consolidation and stack overrun fix From: Benjamin Herrenschmidt To: "H. Peter Anvin" Cc: Frederic Weisbecker , Linus Torvalds , Thomas Gleixner , LKML , Paul Mackerras , Ingo Molnar , Peter Zijlstra , James Hogan , "James E.J. Bottomley" , Helge Deller , Martin Schwidefsky , Heiko Carstens , "David S. Miller" , Andrew Morton Date: Sun, 22 Sep 2013 14:39:14 +1000 In-Reply-To: <523E4F8A.7020708@zytor.com> References: <1379620267-25191-1-git-send-email-fweisbec@gmail.com> <20130920162603.GA30381@localhost.localdomain> <1379799901.24090.6.camel@pasglop> <523E4F8A.7020708@zytor.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1502 Lines: 34 On Sat, 2013-09-21 at 19:01 -0700, H. Peter Anvin wrote: > On 09/21/2013 02:45 PM, Benjamin Herrenschmidt wrote: > > > > I really don't like the "larger" irq stack ... probably because I can't > > make it work easily :-) See my previous comment about how we get to > > thread_info on ppc. > > > > For the record, I intend to remove thread_info from the stack on x86 and > instead merge it with task_struct as a single structure pointed to with > a percpu variable. Last I looked, our per-cpu codegen was pretty poor... but then we have this "PACA" (somewhat arch specific per-cpu blob that is separate from the rest of per-cpu because of a mix of historical reasons and the fact that it has to be allocated in a specific part of memory at boot time) which we point to directly via a GPR, so we could point to it via PACA. How do you do your per-cpu on x86 ? On powerpc we struggle because we try to dedicate a register (r13) to this PACA (the per-cpu offset hangs off it), but we constantly run into issues where gcc copies r13 to another register and then indexes off that, even accross preempt_enable/disable sections, or worst such as saving/restoring from the stack. We can't seem to get the compiler to treat it appropriately as volatile. Ben. -- 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/