From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from verein.lst.de ([213.95.11.211]:41684 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751981AbdLNNF3 (ORCPT ); Thu, 14 Dec 2017 08:05:29 -0500 Date: Thu, 14 Dec 2017 14:05:28 +0100 From: Christoph Hellwig To: Jason Baron Cc: Christoph Hellwig , Ingo Molnar , Peter Zijlstra , Andrew Morton , Al Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] epoll: use the waitqueue lock to protect ep->wq Message-ID: <20171214130528.GA10791@lst.de> References: <20171206235230.19425-1-hch@lst.de> <20171206235230.19425-2-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Dec 07, 2017 at 11:09:11AM -0500, Jason Baron wrote: > On 12/06/2017 06:52 PM, Christoph Hellwig wrote: > > The eoll code currently always uses the unlocked waitqueue helpers for > > ep->wq, but instead of holding the lock inside the waitqueue around these > > calls, as expected by the epoll code uses its own lock. Given that the > > waitqueue is not exposed to the rest of the kernel this actually works > > ok at the moment, but prevents the epoll locking rules from being > > enforced using lockdep. Remove ep->lock and use the waitqueue lock > > to not only reduce the size of struct eventpoll but also make sure we > > can assert locking invariations in the waitqueue code. > > > > Signed-off-by: Christoph Hellwig > > Probably should also fix the locking comments at the top of > fs/eventpoll.c that refer to ep->lock... Done. Note that while doing this I noticed that the epoll code seems to have sketchy workarounds for the fact that it abused ep->poll as the waitqueue lock that might be able to be removed now. But I don't really dare to touch the guts of this code.