Re: [patch 13/15] epoll: check ep_events_available() upon timeout

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Nov 1, 2020 at 5:08 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> After abc610e01c66 ("fs/epoll: avoid barrier after an epoll_wait(2)
> timeout"), we break out of the ep_poll loop upon timeout, without checking
> whether there is any new events available.  Prior to that patch-series we
> always called ep_events_available() after exiting the loop.

This patch looks overly complicated to me.

It does the exact same thing as the "break" does, except:

 - it does it the non-optimized way without the "avoid spinlock"

 - it sets eavail if there was

It would seem like the *much* simpler patch is to just do this oneliner instead:

    diff --git a/fs/eventpoll.c b/fs/eventpoll.c
    index 4df61129566d..29fa770ce1e3 100644
    --- a/fs/eventpoll.c
    +++ b/fs/eventpoll.c
    @@ -1907,6 +1907,7 @@ static int ep_poll(struct eventpoll *ep,
struct epoll_event __user *events,

                if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS)) {
                        timed_out = 1;
    +                   eavail = 1;
                        break;
                }

and *boom* you're done. That will mean that after a timeout we'll try
one more time to just do that ep_events_available() thing.

I can see no downside to just setting eavail unconditionally and
keeping the code much simpler. Hmm?

             Linus



[Index of Archives]     [Kernel Archive]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]

  Powered by Linux