Christophe Leroy <christophe.le...@c-s.fr> writes: > Le 20/12/2018 à 23:35, Benjamin Herrenschmidt a écrit : >> >>>> /* >>>> * MSR_KERNEL is > 0x10000 on 4xx/Book-E since it include MSR_CE. >>>> @@ -205,20 +208,46 @@ transfer_to_handler_cont: >>>> mflr r9 >>>> lwz r11,0(r9) /* virtual address of handler */ >>>> lwz r9,4(r9) /* where to go when done */ >>>> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PERF_EVENTS) >>>> + mtspr SPRN_NRI, r0 >>>> +#endif >>> >>> That's not part of your patch, it's already in the tree. >> >> Yup rebase glitch. >> >> .../... >> >>> I tested it on the 8xx with the below changes in addition. No issue seen >>> so far. >> >> Thanks ! >> >> I'll merge that in. > > I'm currently working on a refactorisation and simplification of > exception and syscall entry on ppc32. > > I plan to take your patch in my serie as it helps quite a bit. I hope > you don't mind. I expect to come out with a series this week.
Ben's AFK so go ahead and pull it in to your series if that helps you. >> The main obscure area is that business with the irqsoff tracer and thus >> the need to create stack frames around calls to trace_hardirqs_* ... we >> do it in some places and not others, but I've not managed to make it >> crash either. I need to get to the bottom of that, and possibly provide >> proper macro helpers like ppc64 has to do it. > > I can't see anything special around this in ppc32 code. As far as I > understand, a stack frame is put in place when there is a need to > save and restore some volatile registers. At the places where nothing > needs to be saved, nothing is done. I think that's the normal way for > any function call, isn't it ? The concern was that the irqsoff tracer was doing __builtin_return_address(1) (or some number > 0) and that crashes if there aren't sufficiently many stack frames available. See ftrace_return_address. Possibly the answer is that we don't have CONFIG_FRAME_POINTER and so we get the empty version of that. cheers