From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH] epoll: Fix spurious lockdep warnings Date: Tue, 13 Sep 2011 14:16:03 -0700 Message-ID: <20110913141603.25614d00.akpm@google.com> References: <1312913515-432-1-git-send-email-nelhage@nelhage.com> <20110908000429.GK10700@zod.bos.redhat.com> <20110913202248.GA6580@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Josh Boyer , Nelson Elhage , Alexander Viro , Davide Libenzi , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Paul Bolle , stable@kernel.org To: Jason Baron Return-path: In-Reply-To: <20110913202248.GA6580@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 13 Sep 2011 16:22:48 -0400 Jason Baron wrote: > 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... I have already fixed up epoll-limit-paths.patch. You're planning on sending a new version of that patch. Please do base that on epoll-fix-spurious-lockdep-warnings.patch.