From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@lst.de>
Cc: Russell King <rmk@arm.linux.org.uk>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux- <kernel@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linus Walleij <linus.walleij@linaro.org>,
Russell King <linux@armlinux.org.uk>,
Christian Brauner <christian.brauner@ubuntu.com>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 5/9] ARM: oabi-compat: rework epoll_wait/epoll_pwait emulation
Date: Tue, 8 Sep 2020 22:56:19 +0200 [thread overview]
Message-ID: <CAK8P3a30Ezn9MhN6YG+c_eCedo=HGp2-uUN6fC218f96TBFK=Q@mail.gmail.com> (raw)
In-Reply-To: <20200908062002.GD13930@lst.de>
On Tue, Sep 8, 2020 at 8:20 AM Christoph Hellwig <hch@lst.de> wrote:
> > @@ -264,68 +266,24 @@ asmlinkage long sys_oabi_epoll_ctl(int epfd, int op, int fd,
> > return do_epoll_ctl(epfd, op, fd, &kernel, false);
> > }
> >
> > -static long do_oabi_epoll_wait(int epfd, struct oabi_epoll_event __user *events,
> > - int maxevents, int timeout)
> > +struct epoll_event __user *
> > +epoll_put_uevent(__poll_t revents, __u64 data, struct epoll_event __user *uevent)
> > {
> > + if (in_oabi_syscall()) {
> > + struct oabi_epoll_event *oevent = (void __user *)uevent;
> >
> > + if (__put_user(revents, &oevent->events) ||
> > + __put_user(data, &oevent->data))
> > + return NULL;
> >
> > + return (void __user *)uevent+1;
FWIW, this line needs to be
return (void __user *)(oevent+1);
It turns out that while I thought I had tested this already, my earlier
tests were on the EABI Debian 5 instead of the OABI version of the
same distro. I reproduced it both ways now and LTP successfully
found that bug ;-)
> I wonder if we'd be better off doing the in_oabi_syscall() branch in
> the common code. E.g. rename in_oabi_syscall to in_legacy_syscall and
> stub it out for all other architectures. Then just do
>
> if (in_oabi_syscall()
> legacy_syscall_foo_bit();
> else
> normal_syscall_foo_bit();
>
> in common code, where so far only arm provides
> legacy_syscall_foo_bit().
I tried out different ways, the first one I had was with an #ifdef in the
C code that I did not like much.
Moving the different code path into common code would avoid that
#ifdef but also put the rather obscure oabi-compat code into a
much more prominent location. I'd prefer to keep it out of there
as much as possible and hope we don't need to do this anywhere
else. x86-32 has some similar issues with struct layout, but that
already goes through the normal compat layer on 64-bit kernels.
> Tons of long lines again in this patch..
Fixed now.
Arnd
prev parent reply other threads:[~2020-09-08 20:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200907153701.2981205-1-arnd@arndb.de>
2020-09-07 15:36 ` [PATCH 5/9] ARM: oabi-compat: rework epoll_wait/epoll_pwait emulation Arnd Bergmann
2020-09-08 6:20 ` Christoph Hellwig
2020-09-08 20:56 ` Arnd Bergmann [this message]
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='CAK8P3a30Ezn9MhN6YG+c_eCedo=HGp2-uUN6fC218f96TBFK=Q@mail.gmail.com' \
--to=arnd@arndb.de \
--cc=akpm@linux-foundation.org \
--cc=christian.brauner@ubuntu.com \
--cc=hch@lst.de \
--cc=kernel@vger.kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=rmk@arm.linux.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;
as well as URLs for NNTP newsgroup(s).