[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABeXuvoOEW9+5BPiDN+2S1boyMSg+csvSAd4ue03TB+yEO6dLg@mail.gmail.com>
Date: Sat, 15 Sep 2018 11:37:38 -0700
From: Deepa Dinamani <deepa.kernel@...il.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Alexander Viro <viro@...iv.linux.org.uk>,
Thomas Gleixner <tglx@...utronix.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
y2038 Mailman List <y2038@...ts.linaro.org>,
Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
linux-aio <linux-aio@...ck.org>
Subject: Re: [PATCH v2 4/5] pselect6: use __kernel_timespec
On Sat, Sep 15, 2018 at 8:28 AM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Sat, Sep 15, 2018 at 7:09 AM Deepa Dinamani <deepa.kernel@...il.com> wrote:
>
> > +#if defined(CONFIG_64BIT_TIME)
> > +
> > +COMPAT_SYSCALL_DEFINE6(pselect6_time64, int, n, compat_ulong_t __user *, inp,
> > + compat_ulong_t __user *, outp, compat_ulong_t __user *, exp,
> > + struct __kernel_timespec __user *, tsp, void __user *, sig)
>
> I got a link error here since compat_sys_pselect6_time64 and
> compat_sys_ppoll_time64 are only defined when CONFIG_64BIT_TIME
> is set.
>
> I did not think we would select this symbol on arm64, is that a mistake
> on my side, or should the #ifdef check be removed?
But, this is a compat syscall.
When we introduced this CONFIG_64BIT_TIME we planned to use it for
compat syscalls also is my understanding.
config 64BIT_TIME
def_bool ARCH_HAS_64BIT_TIME
help
This should be selected by all architectures that need to support
new system calls with a 64-bit time_t. This is relevant on all 32-bit
architectures, and 64-bit architectures as part of compat syscall
handling.
This means it should be set on 64 bit architechtures also right?
If we don't have the #ifdef here then we have an entry point from
userspace defined and Thomas had pointed out that it was a security
hole.
-Deepa
Powered by blists - more mailing lists