linux-kernel - Re: kerneloops.org: 2.6.28-rc regression in epoll (list corruption)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 26 Oct 2008 11:58:06 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Arjan van de Ven <arjan@...radead.org>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, davidel@...ilserver.org,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: kerneloops.org: 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)
> 
> http://www.kerneloops.org/searchweek.php?search=ep_poll_callback
> 
> 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 
all..

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 
confirmation.

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.

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/