On Mon, Nov 2, 2020 at 11:55 AM Soheil Hassas Yeganeh <soheil@xxxxxxxxxx> wrote:
>
> Given that you're calling ep_events_available() under lock, I think
> this should address the inefficiency for the non-racy timeout case, I
> mentioned above. The remaining races are preexisting and all result in
> spurious events, which should be fine.
Well, they might result in not seeing events that are there, but for
that case we end up going the logn way around and doing the "wait for
events" code, and that should take care of it, I guess.
So it's racy, but it gets fixed up later regardless of which way it
races, I think.
It might be worth a comment or two.
And that "goto fetch_events" thing might be worth writing as an actual
loop, rather than the pointless one I removed.
I suspect that old pointless loop might have been historical (some
kind of "loop waiting for event"), since that's how those things are
usually written. I didn't go and look at the history.
Anyway, I've dropped the original 13/15 patch, buit I'll apply the
test-case one (14/15) even if it might now fail in the current state.
I hope that you will end up submitting some cleaned-up (and tested!)
version of that patch I cobbled together - I'll archive this thread
for now on the assumption that the resolution of all this will come
back to me later...
Linus
