All of lore.kernel.org
 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 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.