On 2017/06/22 11:08PM, Nicholas Piggin wrote: > On Thu, 22 Jun 2017 21:07:46 +1000 > Michael Ellerman <m...@ellerman.id.au> wrote: > > > Nicholas Piggin <npig...@gmail.com> writes: > > > > > On Thu, 22 Jun 2017 00:08:39 +0530 > > > "Naveen N. Rao" <naveen.n....@linux.vnet.ibm.com> wrote: > > > > > >> Convert some of the symbols into private symbols and blacklist > > >> system_call_common() and system_call() from kprobes. We can't take a > > >> trap at parts of these functions as either MSR_RI is unset or the kernel > > >> stack pointer is not yet setup. > > >> > > >> Reviewed-by: Masami Hiramatsu <mhira...@kernel.org> > > >> Signed-off-by: Naveen N. Rao <naveen.n....@linux.vnet.ibm.com> > > > > > > I don't have a problem with this bunch of system call labels > > > going private. They've never added much for me in profiles. > > > > > > Reviewed-by: Nicholas Piggin <npig...@gmail.com>
Thanks for the review. > > > > > > Semi-related question, why is system_call: where it is? > > > > Ancient history. > > > > We used to have: > > > > bne syscall_dotrace > > syscall_dotrace_cont: > > cmpldi 0,r0,NR_syscalls > > bge- syscall_enosys > > > > system_call: /* label this so stack traces look sane > > */ > > > > > > So it was there to hide syscall_dotrace_cont from back traces. > > > > But we made syscall_dotrace_cont local in 2012 and then removed it > > entirely in 2015. > > > > > Should we move it up to right after the mtmsrd / wrteei instruction? > > > (obviously for another patch). It's pretty common to get PMU > > > interrupts coming in right after mtmsr and this makes profiles split > > > the syscall into two which is annoying. > > > > Move it wherever makes sense and gives good back traces. > > I'd be in favour of moving it to right after the interurpt enable. > I suppose you'd want a separate patch for that though. But we could > put it in this series since we're changing a lot of labels. Sure, I'll add a patch that does that. - Naveen