Re: [PATCH 05/12] update FTRACE_SYSCALL_MAX

Paul Mundt
2009-08-24T14:37:47Z

On Mon, Aug 24, 2009 at 04:34:20PM +0200, Frederic Weisbecker wrote:
> On Mon, Aug 24, 2009 at 11:15:39PM +0900, Paul Mundt wrote:
> > On Mon, Aug 24, 2009 at 10:06:29AM -0400, Jason Baron wrote:
> > > I don't see how its used as 'NR_syscalls - 1' on x86,
> > > arch_init_ftrace_syscalls() does:
> > >
> > > for (i = 0; i < FTRACE_SYSCALL_MAX; i++) {
> > > meta = find_syscall_meta(psys_syscall_table[i]);
> > > syscalls_metadata[i] = meta;
> > > }
> > >
> > > So the last syscall should not be skipped.
> > >
> >
> > In today's -next:
> >
> > #ifdef CONFIG_X86_64
> > # define FTRACE_SYSCALL_MAX 299
> > #else
> > # define FTRACE_SYSCALL_MAX 337
> > #endif
> >
> > unistd_32.h:
> >
> > #define __NR_reflinkat 337
> >
> > unistd_64.h:
> >
> > #define __NR_reflinkat 299
> >
> > The first syscall starts at 0, but I don't see how this last syscall is
> > handled. If there were a __NR_syscalls 300 and 338 respectively, that
> > would seem to do the right thing. Or am I missing something?
>
>
> Yeah, I guess what we need here is NR_syscalls + 1.
>
No, just NR_syscalls. NR_syscalls has always been last valid + 1. At
least this is how all architectures are using it, it just seems to have
gone missing from x86.

So having said that, it looks like s390 got it right, while x86 has an
off-by-1, and sh foolishly followed x86 ;-)