linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Davide Libenzi <davidel@xmailserver.org>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [patch] add epoll compat code to kernel/compat.c ...
Date: Sun, 11 Feb 2007 15:18:06 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0702111504020.24568@alien.or.mcafeemobile.com> (raw)
In-Reply-To: <20070211214734.GB8631@osiris.ibm.com>

On Sun, 11 Feb 2007, Heiko Carstens wrote:

> On Sun, Feb 11, 2007 at 12:15:24PM -0800, Davide Libenzi wrote:
> > 
> > Add epoll compat_ code to kernel/compat.c. IA64 and ARM-OABI are currently 
> > using their own version of epoll compat_ code and they could probably wire 
> > to the new common code. Patch over 2.6.20.
> > + * epoll (fs/eventpoll.c) compat bits follow ...
> > + */
> > +struct compat_epoll_event {
> > +	u32 events;
> > +	u32 data[2];
> > +};
> > +
> >[...]
> > +
> > + * We need the compat layer over the epoll_event structure, only if the offset
> > + * of the __u64 data member is not 4 (size of the events member that precedes the
> > + * data one).
> > + */
> > +#define EPOLL_NEED_EVENT_COMPAT() (offsetof(struct epoll_event, data) != 4)
> 
> With
> 
> struct epoll_event {
>         __u32 events;
>         __u64 data;
> };
> 
> this won't work on s390. offsetof(struct epoll_event, data) is 8 on both
> 31 bit and 64 bit. So it will do the conversion and corrupt all the data.
> Actually we would only need the compat conversion for the sigset_t stuff.

Yup, that's broken not only on s390, but on every arch with alignof(u64) == 8
in 32 bits mode.
The assumption was that for cases like the above, you simply wouldn't wire 
the compat_ version. That is true for epoll_wait and epoll_ctl, where the 
only need for compat was the "struct epoll_event". But that's not true for 
epoll_pwait, since this one needs to be wired because of the sigset_t.
On top of sigset_t, epoll_pwait may need "struct epoll_event" translation.
Now, that *really* sux because two versions of compat_epoll_pwait are 
needed, once that does sigset_t translation only, and one that does 
sigset_t + "struct epoll_event".



> But then again I thought most 32 bit architectures would add a 4 byte
> pad between events and data, no?

i386 does not, for example ;)



> Maybe we need some arch dependent struct compat_epoll_event and have
> something like
> #define EPOLL_NEED_EVENT_COMPAT() \
> (offsetof(struct epoll_event, data) != offsetof(struct compat_epoll_event, data))
> 
> ?

No, it won't work. Unless there is (or we define) a per-arch macro that 
tells us how the 32 bits mode align an u64, I'm afraid we can't do any 
smart tricks and we need to have the double compat_epoll_pwait.



- Davide



      reply	other threads:[~2007-02-11 23:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-11 20:15 [patch] add epoll compat code to kernel/compat.c Davide Libenzi
2007-02-11 21:47 ` Heiko Carstens
2007-02-11 23:18   ` Davide Libenzi [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=Pine.LNX.4.64.0702111504020.24568@alien.or.mcafeemobile.com \
    --to=davidel@xmailserver.org \
    --cc=akpm@linux-foundation.org \
    --cc=dwmw2@infradead.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    /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).