Messages in this thread | | | Date | Wed, 26 Aug 2009 09:47:36 +0200 | From | Heiko Carstens <> | Subject | Re: [PATCH 08/12] add trace events for each syscall entry/exit |
| |
On Wed, Aug 26, 2009 at 12:09:01AM +0200, Frederic Weisbecker wrote: > On Tue, Aug 25, 2009 at 11:40:21PM +0200, Frederic Weisbecker wrote: > > On Tue, Aug 25, 2009 at 02:50:27PM +0200, Hendrik Brueckner wrote: > > > Most arch syscall_get_nr() implementations returns -1 if the syscall > > > number is not valid. Accessing the bit field without a check might > > > result in a kernel oops (at least I saw it on s390 for ftrace selftest). > > > > > > Before this change, this problem did not occur, because the invalid > > > syscall number (-1) caused syscall_nr_to_meta() to return NULL. > > > > > > There are at least two scenarios where syscall_get_nr() can return -1: > > > > > > 1. For example, ptrace stores an invalid syscall number, and thus, > > > tracing code resets it. > > > (see do_syscall_trace_enter in arch/s390/kernel/ptrace.c) > > > > > > 2. The syscall_regfunc() (kernel/tracepoint.c) sets the TIF_SYSCALL_FTRACE > > > (now: TIF_SYSCALL_TRACEPOINT) flag for all threads which includes > > > kernel threads. > > > However, the ftrace selftest triggers a kernel oops when testing syscall > > > trace points: > > > - The kernel thread is started as ususal (do_fork()), > > > - tracing code sets TIF_SYSCALL_FTRACE, > > > - the ret_from_fork() function is triggered and starts > > > ftrace_syscall_exit() with an invalid syscall number. > > > > > > To avoid these scenarios, I suggest to check the syscall_nr. > > > > > > [...] > > > > > > Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> > > > > > > > > I'm queueing this one for .32 > > > > Thanks. > > Btw it would be nice to have an ack from s390 maintainers. > Martin, Heiko, no problem with this patch?
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
| |