Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753383AbcJCRFq (ORCPT ); Mon, 3 Oct 2016 13:05:46 -0400 Received: from quartz.orcorp.ca ([184.70.90.242]:35807 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752342AbcJCRFj (ORCPT ); Mon, 3 Oct 2016 13:05:39 -0400 Date: Mon, 3 Oct 2016 11:05:33 -0600 From: Jason Gunthorpe To: Vegard Nossum Cc: LKML , stable , Greg Kroah-Hartman , Devesh Sharma , Yishai Hadas , Leon Romanovsky , Doug Ledford 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.151 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 683 Lines: 17 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