From: Segher Boessenkool <segher@kernel.crashing.org> To: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Michael Ellerman <mpe@ellerman.id.au>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org>, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v4 2/2] powerpc/irq: inline call_do_irq() and call_do_softirq() Date: Sat, 7 Dec 2019 11:40:57 -0600 [thread overview] Message-ID: <20191207174057.GY3152@gate.crashing.org> (raw) In-Reply-To: <2a22feca-d6d6-6cb0-6c76-035234fa8742@c-s.fr> On Sat, Dec 07, 2019 at 10:42:28AM +0100, Christophe Leroy wrote: > Le 06/12/2019 à 21:59, Segher Boessenkool a écrit : > >If the compiler can see the callee wants the same TOC as the caller has, > >it does not arrange to set (and restore) it, no. If it sees it may be > >different, it does arrange for that (and the linker then will check if > >it actually needs to do anything, and do that if needed). > > > >In this case, the compiler cannot know the callee wants the same TOC, > >which complicates thing a lot -- but it all works out. > > Do we have a way to make sure which TOC the functions are using ? Is > there several TOC at all in kernel code ? Kernel modules have their own TOC, I think? > >I think things can still go wrong if any of this is inlined into a kernel > >module? Is there anything that prevents this / can this not happen for > >some fundamental reason I don't see? > > This can't happen can it ? > do_softirq_own_stack() is an outline function, defined in powerpc irq.c > Its only caller is do_softirq() which is an outline function defined in > kernel/softirq.c > > That prevents inlining, doesn't it ? Hopefully, sure. Would be nice if it was clearer that this works... It is too much like working by chance, the way it is :-( > Anyway, until we clarify all this I'll limit my patch to PPC32 which is > where the real benefit is I guess. > > At the end, maybe the solution should be to switch to IRQ stack > immediately in the exception entry as x86_64 do ? > > And do_softirq_own_stack() could be entirely written in assembly like > x86_64 as well ? Maybe? I'm out of my depth there. Segher
WARNING: multiple messages have this Message-ID (diff)
From: Segher Boessenkool <segher@kernel.crashing.org> To: Christophe Leroy <christophe.leroy@c-s.fr> Cc: linuxppc-dev@lists.ozlabs.org, Paul Mackerras <paulus@samba.org>, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 2/2] powerpc/irq: inline call_do_irq() and call_do_softirq() Date: Sat, 7 Dec 2019 11:40:57 -0600 [thread overview] Message-ID: <20191207174057.GY3152@gate.crashing.org> (raw) In-Reply-To: <2a22feca-d6d6-6cb0-6c76-035234fa8742@c-s.fr> On Sat, Dec 07, 2019 at 10:42:28AM +0100, Christophe Leroy wrote: > Le 06/12/2019 à 21:59, Segher Boessenkool a écrit : > >If the compiler can see the callee wants the same TOC as the caller has, > >it does not arrange to set (and restore) it, no. If it sees it may be > >different, it does arrange for that (and the linker then will check if > >it actually needs to do anything, and do that if needed). > > > >In this case, the compiler cannot know the callee wants the same TOC, > >which complicates thing a lot -- but it all works out. > > Do we have a way to make sure which TOC the functions are using ? Is > there several TOC at all in kernel code ? Kernel modules have their own TOC, I think? > >I think things can still go wrong if any of this is inlined into a kernel > >module? Is there anything that prevents this / can this not happen for > >some fundamental reason I don't see? > > This can't happen can it ? > do_softirq_own_stack() is an outline function, defined in powerpc irq.c > Its only caller is do_softirq() which is an outline function defined in > kernel/softirq.c > > That prevents inlining, doesn't it ? Hopefully, sure. Would be nice if it was clearer that this works... It is too much like working by chance, the way it is :-( > Anyway, until we clarify all this I'll limit my patch to PPC32 which is > where the real benefit is I guess. > > At the end, maybe the solution should be to switch to IRQ stack > immediately in the exception entry as x86_64 do ? > > And do_softirq_own_stack() could be entirely written in assembly like > x86_64 as well ? Maybe? I'm out of my depth there. Segher
next prev parent reply other threads:[~2019-12-07 17:41 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-10 5:36 [PATCH v4 1/2] powerpc/irq: bring back ksp_limit management in C functions Christophe Leroy 2019-10-10 5:36 ` Christophe Leroy 2019-10-10 5:36 ` [PATCH v4 2/2] powerpc/irq: inline call_do_irq() and call_do_softirq() Christophe Leroy 2019-10-10 5:36 ` Christophe Leroy 2019-11-21 6:14 ` Michael Ellerman 2019-11-21 6:14 ` Michael Ellerman 2019-11-21 10:15 ` Segher Boessenkool 2019-11-21 10:15 ` Segher Boessenkool 2019-11-25 10:32 ` Michael Ellerman 2019-11-25 10:32 ` Michael Ellerman 2019-11-25 14:25 ` Segher Boessenkool 2019-11-25 14:25 ` Segher Boessenkool 2019-11-27 13:50 ` Christophe Leroy 2019-11-27 13:50 ` Christophe Leroy 2019-11-27 14:59 ` Segher Boessenkool 2019-11-27 14:59 ` Segher Boessenkool 2019-11-27 15:15 ` Christophe Leroy 2019-11-27 15:15 ` Christophe Leroy 2019-11-29 18:46 ` Segher Boessenkool 2019-11-29 18:46 ` Segher Boessenkool 2019-12-04 4:32 ` Christophe Leroy 2019-12-04 4:32 ` Christophe Leroy 2019-12-06 20:59 ` Segher Boessenkool 2019-12-06 20:59 ` Segher Boessenkool 2019-12-07 9:42 ` Christophe Leroy 2019-12-07 9:42 ` Christophe Leroy 2019-12-07 17:40 ` Segher Boessenkool [this message] 2019-12-07 17:40 ` Segher Boessenkool 2019-12-09 10:53 ` Michael Ellerman 2019-12-09 10:53 ` Michael Ellerman 2019-12-19 6:57 ` Christophe Leroy 2019-12-19 6:57 ` Christophe Leroy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191207174057.GY3152@gate.crashing.org \ --to=segher@kernel.crashing.org \ --cc=benh@kernel.crashing.org \ --cc=christophe.leroy@c-s.fr \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=mpe@ellerman.id.au \ --cc=paulus@samba.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.