From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752141AbdLGGMT (ORCPT <rfc822;w@1wt.eu>);
        Thu, 7 Dec 2017 01:12:19 -0500
Received: from mail-wm0-f66.google.com ([74.125.82.66]:34388 "EHLO
        mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750780AbdLGGMR (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 7 Dec 2017 01:12:17 -0500
X-Google-Smtp-Source: AGs4zMYMOFch27Rt9j/swPat1ApxBcnktQOR4XYCli5EfIMlMJSH1SMfEmJ+qLElEzRPh7Rro+ooug==
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>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@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