From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Baron Subject: Re: [PATCH] epoll: Fix spurious lockdep warnings Date: Tue, 13 Sep 2011 16:22:48 -0400 Message-ID: <20110913202248.GA6580@redhat.com> References: <1312913515-432-1-git-send-email-nelhage@nelhage.com> <20110908000429.GK10700@zod.bos.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Nelson Elhage , Alexander Viro , Davide Libenzi , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Paul Bolle , stable@kernel.org, akpm@linux-foundation.org To: Josh Boyer Return-path: Content-Disposition: inline In-Reply-To: <20110908000429.GK10700@zod.bos.redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Sep 07, 2011 at 08:04:29PM -0400, Josh Boyer wrote: > On Tue, Aug 09, 2011 at 02:11:55PM -0400, Nelson Elhage wrote: > > epoll can acquire recursively acquire ep->mtx on multiple "struct > > eventpoll"s at once in the case where one epoll fd is monitoring > > another epoll fd. This is perfectly OK, since we're careful about the > > lock ordering, but it causes spurious lockdep warnings. Annotate the > > recursion using mutex_lock_nested, and add a comment explaining the > > nesting rules for good measure. > > > > Recent versions of systemd are triggering this, and it can also be > > demonstrated with the following trivial test program: > > > > --------------------8<-------------------- > > > > 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<-------------------- > > > > Cc: stable@kernel.org > > Reported-by: Paul Bolle > > Tested-by: Paul Bolle > > Signed-off-by: Nelson Elhage > > Any progress on this heading upstream? > Patch looks good to me, feel free to add: Acked-by: Jason Baron However, I am going to have to re-base the epoll path I recently posted: https://lkml.org/lkml/2011/9/2/295, if this goes in first. Perhaps, Andrew (added to the 'cc), can help us sort out the ordering... Thanks, -Jason