From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9E843C00449 for ; Wed, 3 Oct 2018 09:30:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 392572089F for ; Wed, 3 Oct 2018 09:30:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 392572089F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=c-s.fr Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727687AbeJCQSG (ORCPT ); Wed, 3 Oct 2018 12:18:06 -0400 Received: from pegase1.c-s.fr ([93.17.236.30]:6125 "EHLO pegase1.c-s.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726216AbeJCQSG (ORCPT ); Wed, 3 Oct 2018 12:18:06 -0400 Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 42Q9jd4lxVz9ttBs; Wed, 3 Oct 2018 11:30:29 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id yGs7P_owGSBg; Wed, 3 Oct 2018 11:30:29 +0200 (CEST) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 42Q9jd47LZz9ttBf; Wed, 3 Oct 2018 11:30:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 397E48B8C5; Wed, 3 Oct 2018 11:30:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 3KTNbf7wHOoV; Wed, 3 Oct 2018 11:30:30 +0200 (CEST) Received: from PO15451 (po15451.idsi0.si.c-s.fr [172.25.231.3]) by messagerie.si.c-s.fr (Postfix) with ESMTP id DE01C8B8CD; Wed, 3 Oct 2018 11:30:29 +0200 (CEST) Subject: Re: [RFC PATCH v3 4/7] powerpc: regain entire stack space To: Nicholas Piggin Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , aneesh.kumar@linux.vnet.ibm.com, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org References: <8108de51846b7b34e4732753b2b65e435b6a2b7a.1538396659.git.christophe.leroy@c-s.fr> <20181003153448.3fb64e19@roar.ozlabs.ibm.com> <6a539614-abb6-d468-ccba-2e3c1fb8b680@c-s.fr> <20181003163024.281254bf@roar.ozlabs.ibm.com> <38d58749-c058-a6d7-1ca2-23abe9dd34a3@c-s.fr> <20181003170736.34082f4d@roar.ozlabs.ibm.com> From: Christophe LEROY Message-ID: Date: Wed, 3 Oct 2018 11:30:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181003170736.34082f4d@roar.ozlabs.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 03/10/2018 à 09:07, Nicholas Piggin a écrit : > On Wed, 3 Oct 2018 08:45:25 +0200 > Christophe LEROY wrote: > >> Le 03/10/2018 à 08:30, Nicholas Piggin a écrit : >>> On Wed, 3 Oct 2018 07:52:59 +0200 >>> Christophe LEROY wrote: >>> >>>> Le 03/10/2018 à 07:34, Nicholas Piggin a écrit : >>>>> On Mon, 1 Oct 2018 12:30:25 +0000 (UTC) >>>>> Christophe Leroy wrote: >>>>> >>>>>> thread_info is not anymore in the stack, so the entire stack >>>>>> can now be used. >>>>> >>>>> Nice. >>>>> >>>>>> >>>>>> In the meantime, all pointers to the stacks are not anymore >>>>>> pointers to thread_info so this patch changes them to void* >>>>> >>>>> Wasn't this previously effectively already the case with patch >>>>> 3/7? You had thread_info sized space left there, but it was not >>>>> used or initialized right? Does it make sense to move this part >>>>> of it to the previous patch? >>>> >>>> Not really. >>>> >>>> In 3/7 I changed the prototypes of two functions that really used the >>>> pointer as a task pointer only. >> >> I meant 2/7 here sorry. >> >>>> >>>> Here it change things that before 4/7 were really used as both stack >>>> pointers and thread_info pointers. >> >> And here I meant 3/7 >> >>> >>> What uses it as a thread_info pointer? It seems more like a stack >>> with some amount of unused space in it but that's all. >> >> Before 3/7, we have >> >> void do_softirq_own_stack(void) >> { >> struct thread_info *curtp, *irqtp; >> >> curtp = current_thread_info(); >> irqtp = softirq_ctx[smp_processor_id()]; >> irqtp->task = curtp->task; >> irqtp->flags = 0; >> call_do_softirq(irqtp); >> irqtp->task = NULL; >> >> /* Set any flag that may have been set on the >> * alternate stack >> */ >> if (irqtp->flags) >> set_bits(irqtp->flags, &curtp->flags); >> } >> >> After 3/7, we have >> >> void do_softirq_own_stack(void) >> { >> struct thread_info *irqtp; >> >> irqtp = softirq_ctx[smp_processor_id()]; >> call_do_softirq(irqtp); >> } >> >> >> So now only we can change irqtp to void* can't we ? > > In patch 3 we can, right? That's what I mean by moving from > thread_info * to void * in patch 3 rather than 4. Ah ok, that's what you meant. Sorry. > > But if you prefer not to, it's fine. Maybe it keeps patch 3 > a little smaller. Yes indeed, that's the idea, keep patch 3 to the strict minimum and do cleanups afterwards. Christophe > > Thanks, > Nick >