From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Date: Thu, 7 Dec 2017 07:12:13 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Christoph Hellwig <hch@lst.de>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>,
        Ingo Molnar <mingo@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Jason Baron <jbaron@akamai.com>, 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: <20171207061213.nhm4p5pghfsglkgy@gmail.com>
References: <20171206235230.19425-1-hch@lst.de>
 <20171206235230.19425-2-hch@lst.de>
 <20171207004914.lxu2dz6cmxgnrou3@gmail.com>
 <7AFB0C38-3D2E-45E8-9092-CA424BFD32B6@dilger.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7AFB0C38-3D2E-45E8-9092-CA424BFD32B6@dilger.ca>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>


* Andreas Dilger <adilger@dilger.ca> wrote:

> > On Dec 6, 2017, at 17:49, Ingo Molnar <mingo@kernel.org> wrote:
> > 
> > This exposes some waitqueue internals, but AFAICS the FUSE code already does a 
> > similar trick with fiq->waitq.lock so there's precedent.
> 
> What about waitqueue_lock() and waitqueue_unlock() helpers that
> lock and unlock, to avoid exposing the internals?  Or would that add
> confusion by making users think they need their own waitqueue locking?

Right now there are just two users (FUSE and epoll), and both are well-maintained, 
essentially core kernel code - I'd rather prefer the readability of explicitly 
writing out the locking/unlocking pattern.

So while it's a mild layering violation, it's also a valid looking optimization.

Thanks,

	Ingo