Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote:
> First, thanks for working on this issue.
No problem!
> It seems the real problem is the epi->event.events = event->events;
> which is done without taking ep->lock
Yes. I am hoping it is possible to do it without a lock there,
but your change is more obviously correct.
> While a smp_mb() could reduce the race window, I believe there is still
> a race, and the following patch would close it.
I'm not an experienced kernel hacker, can you describe where the race
would be?
> diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> index be56b21..25e5c53 100644
> --- a/fs/eventpoll.c
> +++ b/fs/eventpoll.c
> @@ -1313,7 +1313,10 @@ static int ep_modify(struct eventpoll *ep, struct epitem *epi, struct epoll_even
> * otherwise we might miss an event that happens between the
> * f_op->poll() call and the new event set registering.
> */
> + spin_lock_irq(&ep->lock);
> epi->event.events = event->events;
> + spin_unlock_irq(&ep->lock);
> +
> pt._key = event->events;
> epi->event.data = event->data; /* protected by mtx */
> if (epi->event.events & EPOLLWAKEUP) {
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
