On 2016-06-02 18:41:00 +0100, Greg Stark wrote:
> On Thu, Jun 2, 2016 at 6:35 PM, Andres Freund <andres@anarazel.de> wrote:
> > Want me to polish that up and push, or do you want to go back and forth
> > and push yourself?
>
> I'm happy to check if my bits still work if it's not too much hassle
> to go back and forth.
No problem.
> > They should be *after* the multiplications. If arrays of structs are
> > internally misaligned there's nothing we can do.
>
> Well there's not *nothing* we can do. I thought I we were going to
> have to go back and do manual offset calculations to get that right.
The kernel accesses the elements as an array. If the array stride (by
virtue of sizeof) were wrong, we couldn't fix that.
> But with the u64_t element that's probably not necessary. It's a bit
> scary having that be the only thing protecting it but then again it's
> probably exactly why it's there.
I guess the problem occurs due to the kernel checking that the
parameter is correctly aligned to contain an epoll_event array. Which
needs its alignment due to that uint64_t. I rather doubt that the
syscall requires 8 byte alignment because of the 32 vs. 64 bit split;
that problem exists in a *lot* of places...
> Should the maxaligns be there for the non-epoll cases? I tossed them
> in without paying much attention. I really have no idea if they're
> needed on Windows or not for example.
The might not absolutely be needed in some cases today, but I think it's
better to be safe. Who knows what we'll add after the current elements
at some later point.
Greetings,
Andres Freund
