From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nelson Elhage Subject: Re: [PATCH] epoll: Fix spurious lockdep warnings. Date: Sun, 31 Jul 2011 11:16:28 -0400 Message-ID: <20110731151626.GA5952@ksplice.com> References: <1312065022-17890-1-git-send-email-nelhage@nelhage.com> <1312124775.2072.11.camel@t41.thuisdomein> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alexander Viro , linux-fsdevel@vger.kernel.org, Davide Libenzi To: Paul Bolle Return-path: Received: from mail-qy0-f181.google.com ([209.85.216.181]:63133 "EHLO mail-qy0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751829Ab1GaPQb (ORCPT ); Sun, 31 Jul 2011 11:16:31 -0400 Received: by qyk9 with SMTP id 9so2898721qyk.19 for ; Sun, 31 Jul 2011 08:16:30 -0700 (PDT) Content-Disposition: inline In-Reply-To: <1312124775.2072.11.camel@t41.thuisdomein> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Sure -- it's quite simple if you've worked with epoll before. This cut-down version is even simpler than the previous one I had, and I'd be happy to add it to the commit message. --------------------8<-------------------- #include int main(void) { int e1, e2; struct epoll_event evt = { .events = EPOLLIN }; e1 = epoll_create1(0); e2 = epoll_create1(0); epoll_ctl(e1, EPOLL_CTL_ADD, e2, &evt); return 0; } --------------------8<-------------------- - Nelson On Sun, Jul 31, 2011 at 05:06:10PM +0200, Paul Bolle wrote: > On Sat, 2011-07-30 at 18:30 -0400, Nelson Elhage wrote: > > I've tested this on a synthetic epoll test case, that just adds e1 to > > e2 and then does an epoll_wait(). I verified that it caused lockdep > > problems on 3.0 and that this patch fixed it, but I haven't done more > > extensive testing. > > I was unable to come up with such a test case myself. Could you perhaps > share it? > > (Maybe that test case could even be added tot the commit message. I seem > to remember an earlier commit that you were involved with which had a > test case added. That helped me understand eventpoll's interface - at > least enough to pinpoint the problem. Looking at a test case is much > easier than grepping through a program like systemd. Issues in non-test > case programs tend to increase the bug hunting challenge: one is faced > with an issue in an interface one hasn't used before triggered by a > program one hasn't studied before.) > > > Paul, are you able to test systemd against this? > > I hope to do so shortly (ie, in the next 24 hours). > > > Paul Bolle >