Re: epoll_wait returning EFAULT on Linux 3.2.78 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: epoll_wait returning EFAULT on Linux 3.2.78
Date
Msg-id 20835.1464881362@sss.pgh.pa.us
Whole thread Raw
In response to Re: epoll_wait returning EFAULT on Linux 3.2.78  (Greg Stark <stark@mit.edu>)
Responses Re: epoll_wait returning EFAULT on Linux 3.2.78  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> On Thu, Jun 2, 2016 at 3:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I notice that CreateWaitEventSet() is being remarkably cavalier
>> about alignment requirements; maybe it ought to make some effort
>> to ensure that epoll_ret_events is maxaligned.

> That makes a certain amount of sense as This is Debian Sparc64 which
> as I understand it has the kernel compiled in 64-bit mode but not most
> of userland. I bet if I compile Postgres in 64-bit mode it'll turn up
> as an alignment issue in userland before it even reaches the kernel.
> Or maybe not, maybe it's just that __put_user is stricter about
> alignment than really necessary.

Hm.  If you're doing a 32-bit build then we'll likely think that
4-byte alignment *is* maxaligned.  But it's not very hard to believe
that the kernel might be insisting on 8-byte alignment anyway.  That
would be a bug, but one that would easily escape detection for such
a seldom-used kernel call.

We might have to do something to force the pointer to be 8-byte-aligned
even in 32-bit builds.  Ick, but better than falling back to poll().

Can you do a test and see if 8-byte aligning the pointer makes the
EFAULT go away?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Reviewing freeze map code
Next
From: Josh berkus
Date:
Subject: Re: Rename max_parallel_degree?