From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB814C2BA19 for ; Thu, 9 Apr 2020 18:45:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BB68220757 for ; Thu, 9 Apr 2020 18:45:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="cNRMpuq4" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726679AbgDISpQ (ORCPT ); Thu, 9 Apr 2020 14:45:16 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:52260 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726477AbgDISpQ (ORCPT ); Thu, 9 Apr 2020 14:45:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ec6By6jM0nky0YxXbeoKWCzhryIxU+J3YpWKlp335aQ=; b=cNRMpuq4XmR+MbdzNLGNIl5Gw5 26AilBeNESBtw+JDm947/5Lj0TQHojVAPWq/B+ddggAlOMRUuGGCP3JTTQEVFInTdkxT4FHdWr9QE oCWqk0BHGsqBi7eYts23l7DsFWha/FWA5EFi8haC9KoSkbrhUB9Asc0qmqQ7XCmW2u8pvCbMicgp+ gKtG7P9sQ7+iZPrsWfQKpmcsI9HGa0ng1h4H3s7hH14HC5pFvgfRjlS72KCt2cpBsQrhP2sq96VE9 HbKVpLYFfcKNAvoeZyLXIALHFQekrE28/g8mnSscwZYspc0Drual1CRqBh3plP9XUw2CkH/eRTwA3 LxDNOHpg==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jMcAq-0008FP-9i; Thu, 09 Apr 2020 18:45:12 +0000 Date: Thu, 9 Apr 2020 11:45:12 -0700 From: Matthew Wilcox To: Miklos Szeredi Cc: Al Viro , Karel Zak , linux-fsdevel@vger.kernel.org, Kent Overstreet Subject: Re: [PATCH v2] proc/mounts: add cursor Message-ID: <20200409184512.GX21484@bombadil.infradead.org> References: <20200409141619.GF28467@miu.piliscsaba.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200409141619.GF28467@miu.piliscsaba.redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, Apr 09, 2020 at 04:16:19PM +0200, Miklos Szeredi wrote: > Solve this by adding a cursor entry for each open instance. Taking the > global namespace_sem for write seems excessive, since we are only dealing > with a per-namespace list. Instead add a per-namespace spinlock and use > that together with namespace_sem taken for read to protect against > concurrent modification of the mount list. This may reduce parallelism of It occurs to me that this is another place where something like Kent's SIX locks would fit the bill. To recap, that was a mutex with Shared, Intent-to-upgrade and eXclusive states. eXclusive and Shared are like write and read states in our rwsem. The Intent state would allow other Shared users to start, but no more Intent users. You'd have to upgrade to eXclusive state to actually modify the list, so you might have to wait for Shared users to finish the section. Might not work out well in practice for this user, but thought it was worth mentioning.