Date: Mon, 3 Oct 2016 11:05:33 -0600
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Vegard Nossum <vegard.nossum@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
        stable <stable@vger.kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Devesh Sharma <devesh.sharma@broadcom.com>,
        Yishai Hadas <yishaih@mellanox.com>,
        Leon Romanovsky <leon@kernel.org>,
        Doug Ledford <dledford@redhat.com>
Subject: Re: [PATCH 4.4 022/118] IB/uverbs: Fix race between uverbs_close and
 remove_one
Message-ID: <20161003170533.GD6801@obsidianresearch.com>
References: <20160922172938.643879685@linuxfoundation.org>
 <20160922172939.724481707@linuxfoundation.org>
 <CAOMGZ=Ejfr0cE00bFgriOVdjVhxNNZ_tkaRw-cJ_nGJZgw6tbA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOMGZ=Ejfr0cE00bFgriOVdjVhxNNZ_tkaRw-cJ_nGJZgw6tbA@mail.gmail.com>
Sender: stable-owner@vger.kernel.org

On Mon, Oct 03, 2016 at 02:28:40PM +0200, Vegard Nossum wrote:

> This lock is literally called "cleanup mutex" and it's not really
> documented what data it protects. Is there a better solution here?

I agree it is very complex and hard to understand. This is why it
needed patching :| The mutex is in fact pretty much locking
code. (ensuring that ib_uverbs_cleanup_ucontext only runs on one
thread during this race)

There are at least three locks involved in this process. I didn't see
any obvious way to extend any of the other locks to handle this case.

The argument against most simple solutions (eg a rw lock rather than
the srcu) has been performance on these paths.

Jason