[lkml]   [2008]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6.28-rc regression in epoll (list corruption)

On Sun, 26 Oct 2008, Arjan van de Ven wrote:
> This one is upcoming fast (and I just hit it as well)
> seems epoll grew some list corruption....

It sounds very much like f337b9c58332bdecde965b436e47ea4c94d30da0 ("epoll:
drop unnecessary test") deleted a test that wasn't so unnecessary after

That ep_poll_callback() code is:

/* If this file is already in the ready list we exit soon */
if (ep_is_linked(&epi->rdllink))
goto is_linked;

list_add_tail(&epi->rdllink, &ep->rdllist);

and the unnecessary test that was removed looks _very_ much like that kind
of code.

Thomas? Davide?

And if somebody knows how to reproduce this reliably, it would be really
good to hear if doing a revert on that thing just fixed it. It should
revert cleanly - it's the only change to fs/eventpoll.c since 2.6.27.

I'm somewhat inclined to revert it without even getting confirmation,
since I wanted to do an early -rc2 today with all the brown-paper-bag
fixes that have accumulated. But it would be good to get some

Btw, that whole logic in ep_send_events() sounds a bit scary. It says:

We can loop without lock because this is a task private list.

and it's true that "txlist" is a private list, but it still seems to
depend on the fact that none of the "struct epitem"s on that list can be
reached by any other means. And that whole thing depends on the magic
behaviour of 'ep->ovflist', but there are a lot of code sequences that do
*not* seem to test that at all.

Maybe the rqace/bug has always been there (ie some sequence that works
with an "epi->rdllink" without checking ovflist), but the "unnecessary"
test protected us from seeing it in practice.


 \ /
  Last update: 2008-10-26 20:01    [W:0.064 / U:2.016 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site