From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: Russell King <linux@armlinux.org.uk>,
Alexander Viro <viro@zeniv.linux.org.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-arch <linux-arch@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH v2 5/9] ARM: oabi-compat: rework epoll_wait/epoll_pwait emulation
Date: Sat, 26 Sep 2020 20:30:03 +0200 [thread overview]
Message-ID: <CAK8P3a2nZ_Uzq0ivB7vnR620kHb-onYdqMnWnf6KQjZq8gEdpQ@mail.gmail.com> (raw)
In-Reply-To: <20200919053233.GH30063@infradead.org>
On Sat, Sep 19, 2020 at 7:32 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> > index 855aa7cc9b8e..156880943c16 100644
> > --- a/arch/arm/include/asm/syscall.h
> > +++ b/arch/arm/include/asm/syscall.h
> > @@ -28,6 +28,17 @@ static inline int syscall_get_nr(struct task_struct *task,
> > return task_thread_info(task)->syscall & ~__NR_OABI_SYSCALL_BASE;
> > }
> >
> > +static inline bool __in_oabi_syscall(struct task_struct *task)
> > +{
> > + return IS_ENABLED(CONFIG_OABI_COMPAT) &&
> > + (task_thread_info(task)->syscall & __NR_OABI_SYSCALL_BASE);
> > +}
> > +
> > +static inline bool in_oabi_syscall(void)
> > +{
> > + return __in_oabi_syscall(current);
> > +}
> > +
>
> Maybe split these infrastructure additions into a separate helper?
Sorry, I'm not following what you mean by this. Both of the above
are pretty minimal helpers already, in what way could they be split
further?
> So after you argued for this variant I still have minor nitpicks:
>
> I alway find positive ifdefs better where possible, e.g.
>
> #if defined(CONFIG_ARM) && defined(CONFIG_OABI_COMPAT)
> external declaration here
> #else
> the real thing
> #endif
Ok.
> but I still find the fact that the native case goes into the arch
> helper a little weird.
Would you prefer something like this:
static inline struct epoll_event __user *
epoll_put_uevent(__poll_t revents, __u64 data,
struct epoll_event __user *uevent)
{
#if defined(CONFIG_ARM) && defined(CONFIG_OABI_COMPAT)
/* ARM OABI has an incompatible struct layout and needs a
special handler */
extern struct epoll_event __user *
epoll_oabi_put_uevent(__poll_t revents, __u64 data,
struct epoll_event __user *uevent);
if (in_oabi_syscall())
return epoll_oabi_put_uevent(revents, data, uevent);
#endif
if (__put_user(revents, &uevent->events) ||
__put_user(data, &uevent->data))
return NULL;
return uevent+1;
}
That would keep the native case in one place, but also mix in
more architecture specific stuff into the common source location,
which again seems worse to me.
Arnd
next prev parent reply other threads:[~2020-09-26 18:30 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-18 12:46 [PATCH v2 0/9] ARM: remove set_fs callers and implementation Arnd Bergmann
2020-09-18 12:46 ` [PATCH v2 1/9] mm/maccess: fix unaligned copy_{from,to}_kernel_nofault Arnd Bergmann
2020-09-18 12:46 ` [PATCH v2 2/9] ARM: traps: use get_kernel_nofault instead of set_fs() Arnd Bergmann
2020-09-19 5:27 ` Christoph Hellwig
2020-09-18 12:46 ` [PATCH v2 3/9] ARM: oabi-compat: add epoll_pwait handler Arnd Bergmann
2020-09-18 12:46 ` [PATCH v2 4/9] ARM: syscall: always store thread_info->syscall Arnd Bergmann
2020-09-18 12:46 ` [PATCH v2 5/9] ARM: oabi-compat: rework epoll_wait/epoll_pwait emulation Arnd Bergmann
2020-09-19 5:32 ` Christoph Hellwig
2020-09-26 18:30 ` Arnd Bergmann [this message]
2020-09-18 12:46 ` [PATCH v2 6/9] ARM: oabi-compat: rework sys_semtimedop emulation Arnd Bergmann
2020-09-18 12:46 ` [PATCH v2 7/9] ARM: oabi-compat: rework fcntl64() emulation Arnd Bergmann
2020-09-18 12:46 ` [PATCH v2 8/9] ARM: uaccess: add __{get,put}_kernel_nofault Arnd Bergmann
2020-09-18 12:46 ` [PATCH v2 9/9] ARM: uaccess: remove set_fs() implementation Arnd Bergmann
2020-09-19 5:27 ` [PATCH v2 0/9] ARM: remove set_fs callers and implementation Christoph Hellwig
2020-09-25 13:40 ` Arnd Bergmann
2020-09-26 6:49 ` Christoph Hellwig
2021-07-05 6:01 ` Christoph Hellwig
2021-07-22 17:27 ` Arnd Bergmann
2020-09-19 8:19 ` Russell King - ARM Linux admin
2020-09-25 14:08 ` Arnd Bergmann
2020-09-25 15:30 ` 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=CAK8P3a2nZ_Uzq0ivB7vnR620kHb-onYdqMnWnf6KQjZq8gEdpQ@mail.gmail.com \
--to=arnd@arndb.de \
--cc=hch@infradead.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@armlinux.org.uk \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox