linux-kernel - Re: [PATCH 01/40] ftrace syscalls: don't add events for unmapped syscalls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 29 Jun 2010 11:18:38 +1000
From:	Ian Munsie <imunsie@....ibm.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Jason Baron <jbaron@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linuxppc-dev <linuxppc-dev@...abs.org>,
	Ingo Molnar <mingo@...hat.com>,
	Paul Mackerras <paulus@...ba.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Masami Hiramatsu <mhiramat@...hat.com>
Subject: Re: [PATCH 01/40] ftrace syscalls: don't add events for unmapped syscalls

Excerpts from Steven Rostedt's message of Thu Jun 24 01:02:19 +1000 2010:
> > diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
> > index 34e3580..82246ce 100644
> > --- a/kernel/trace/trace_syscalls.c
> > +++ b/kernel/trace/trace_syscalls.c
> > @@ -431,6 +431,14 @@ void unreg_event_syscall_exit(struct ftrace_event_call *call)
> >  int init_syscall_trace(struct ftrace_event_call *call)
> >  {
> >      int id;
> > +    int num;
> > +
> > +    num = ((struct syscall_metadata *)call->data)->syscall_nr;
> > +    if (num < 0 || num >= NR_syscalls) {
> > +        pr_debug("syscall %s metadata not mapped, disabling ftrace event\n",
> > +                ((struct syscall_metadata *)call->data)->name);
> > +        return -ENOSYS;
> > +    }
> 
> Perhaps this should be:
> 
>     if (WARN_ON_ONCE(num < 0 || num >= NR_syscalls)
>         return -ENOSYS;
> 
> -- Steve

Hi Steven,

I don't think this should produce a warning - it signifies that a
syscall defined in the code has not successfully matched a syscall at
boot.

That may signify the matching failed, but it may just as likely signify
that the syscall isn't used on that arch (for instance, if an arch uses
an arch specific implementation in favour of a generic implementation,
or doesn't implement a particular syscall at all that is defined in the
generic code).

The problem case is actually the other way around - when a syscall
number from an arch's syscall table has not successfully mapped to some
syscall meta-data. Patch #37 prints out those cases with KERN_DEBUG so
booting a kernel with loglevel=8 can track them down.

This pr_debug may still be useful, for example to help locate unused
syscalls which can be removed if no arch uses them.

Cheers,
-Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/