lkml.org 
[lkml]   [2019]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: pselect/etc semantics
    > On May 30, 2019, at 8:38 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
    >
    > ebiederm@xmission.com (Eric W. Biederman) writes:
    >
    >> Which means I believe we have a semantically valid change in behavior
    >> that is causing a regression.
    >
    > I haven't made a survey of all of the functions yet but
    > fucntions return -ENORESTARTNOHAND will never return -EINTR and are
    > immune from this problem.
    >
    > AKA pselect is fine. While epoll_pwait can be affected.

    This was my understanding as well.

    > Has anyone contacted Omar Kilani to see if that is his issue?
    > https://lore.kernel.org/lkml/CA+8F9hicnF=kvjXPZFQy=Pa2HJUS3JS+G9VswFHNQQynPMHGVQ@mail.gmail.com/

    Omar was cc-ed when this regression was reported. I did cc him on fix
    and asked if he could try it. We have not heard from him.

    > So far the only regression report I am seeing is from Eric Wong.
    > AKA https://lore.kernel.org/lkml/20190501021405.hfvd7ps623liu25i@dcvr/
    > Are there any others? How did we get to be talking about more
    > than just epoll_pwait?

    This is the only report that I know of. I’m not sure why people
    started talking about pselect. I was also confused why instead of
    reviewing the patch and discussing the fix, we ended up talking about
    how to simplify the code. We have deviated much from what should have
    been a code review.

    -Deepa

    \
     
     \ /
      Last update: 2019-05-30 17:48    [W:4.145 / U:0.512 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site