All of lore.kernel.org
 help / color / mirror / Atom feed
From: Firoz Khan <firoz.khan@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Paul Burton <paul.burton@mips.com>,
	James Hogan <jhogan@kernel.org>,
	"open list:RALINK MIPS ARCHITECTURE" <linux-mips@linux-mips.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Philippe Ombredanne <pombredanne@nexb.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux-Arch <linux-arch@vger.kernel.org>,
	Deepa Dinamani <deepa.kernel@gmail.com>,
	Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Subject: Re: [PATCH v2 1/5] mips: add __NR_syscalls along with __NR_Linux_syscalls
Date: Tue, 20 Nov 2018 12:12:08 +0530	[thread overview]
Message-ID: <CALxhOnjrXLjWNqrAtChw+k5vv5iu39wqAJNqJ9xDdzdv=xihhA@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a2CuryCoZKaOXz=nH_WTAZ7VneNoUYHkKFDLQNQvrkWUg@mail.gmail.com>

Hi Arnd,

On Mon, 19 Nov 2018 at 21:22, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Nov 15, 2018 at 7:14 AM Firoz Khan <firoz.khan@linaro.org> wrote:
> >
> > The 2nd option will be the recommended one. For that, I
> > added the __NR_syscalls macro in uapi/asm/unistd.h along
> > with __NR_Linux_syscalls. The macro __NR_syscalls also
> > added for making the name convention same across all
> > architecture. While __NR_syscalls isn't strictly part of
> > the uapi, having it as part of the generated header to
> > simplifies the implementation. We also need to enclose
> > this macro with #ifdef __KERNEL__ to avoid side effects.
>
> I fear this doesn't work the way you hoped:
>
> > --- a/arch/mips/include/uapi/asm/unistd.h
> > +++ b/arch/mips/include/uapi/asm/unistd.h
> > @@ -391,16 +391,19 @@
> >  #define __NR_rseq                      (__NR_Linux + 367)
> >  #define __NR_io_pgetevents             (__NR_Linux + 368)
> >
> > +#ifdef __KERNEL__
> > +#define __NR_syscalls                  368
> > +#endif
>
> We now have three different definitions of __NR_syscalls,
> one for each ABI. User space previously saw the correct
> one (now it doesn't see any, but that's ok).
>
> >  /*
> >   * Offset of the last Linux o32 flavoured syscall
> >   */
> > -#define __NR_Linux_syscalls            368
> > +#define __NR_Linux_syscalls            __NR_syscalls
>
> so this part part again is ok.
>
> >  #endif /* _MIPS_SIM == _MIPS_SIM_ABI32 */
> >
> >  #define __NR_O32_Linux                 4000
> > -#define __NR_O32_Linux_syscalls                368
> > +#define __NR_O32_Linux_syscalls                __NR_syscalls
>
> but this part is not: Now __NR_O32_Linux_syscalls is defined
> to __NR_syscalls, which may be one of the three values.
> Any usage of __NR_O32_Linux_syscalls in a 64-bit kernel
> is then clearly wrong.
>
> >  #endif /* _MIPS_SIM == _MIPS_SIM_NABI32 */
> >
> >  #define __NR_N32_Linux                 6000
> > -#define __NR_N32_Linux_syscalls                332
> > +#define __NR_N32_Linux_syscalls                __NR_syscalls
>
> Same for this one.

Thanks for the feedback. Will address all the comments.

Firoz

>
>        Arnd

  reply	other threads:[~2018-11-20  6:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-15  6:14 [PATCH v2 0/5] mips: system call table generation support Firoz Khan
2018-11-15  6:14 ` [PATCH v2 1/5] mips: add __NR_syscalls along with __NR_Linux_syscalls Firoz Khan
2018-11-19 15:51   ` Arnd Bergmann
2018-11-20  6:42     ` Firoz Khan [this message]
2018-11-15  6:14 ` [PATCH v2 2/5] mips: add +1 to __NR_syscalls in uapi header Firoz Khan
2018-11-19 15:57   ` Arnd Bergmann
2018-11-15  6:14 ` [PATCH v2 3/5] mips: remove syscall table entries Firoz Khan
2018-11-19 22:29   ` Paul Burton
2018-11-19 22:29     ` Paul Burton
2018-11-20 10:54     ` Arnd Bergmann
2018-11-15  6:14 ` [PATCH v2 4/5] mips: add system call table generation support Firoz Khan
2018-11-19 16:00   ` Arnd Bergmann
2018-11-19 22:35   ` Paul Burton
2018-11-20  7:13     ` Firoz Khan
2018-11-15  6:14 ` [PATCH v2 5/5] mips: generate uapi header and system call table files Firoz Khan
2018-11-19 16:01   ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALxhOnjrXLjWNqrAtChw+k5vv5iu39wqAJNqJ9xDdzdv=xihhA@mail.gmail.com' \
    --to=firoz.khan@linaro.org \
    --cc=arnd@arndb.de \
    --cc=deepa.kernel@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jhogan@kernel.org \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=marcin.juszkiewicz@linaro.org \
    --cc=paul.burton@mips.com \
    --cc=pombredanne@nexb.com \
    --cc=ralf@linux-mips.org \
    --cc=tglx@linutronix.de \
    --cc=y2038@lists.linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.