Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6760477yba; Wed, 1 May 2019 20:05:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqxuY1Ns9e1eHbwrFZ19NwDqub2g1RPbsFKRAHQ4rd3lg3eByekCaCLu+V2D9gmqWqPEuDe3 X-Received: by 2002:a63:5322:: with SMTP id h34mr1382455pgb.413.1556766336825; Wed, 01 May 2019 20:05:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556766336; cv=none; d=google.com; s=arc-20160816; b=gls8ZQnyq0/KuUqfftO2VZ5kx8jMFS6g1VP1220RlEKOmJBUnOgYaSQSZkft0lfIa7 u0rtAwa6ncWr741CrUd9vhIm/TjYHi8C52lm6LRDCvhYTw3KWOVRWooPhYkpLobfhexD 5kK5Vq5XZpfjwg5jJMiTbDYQdzs3VHEw1joRU0etvyJOYb/zJ5NvZpRNHk2bOLaVA2T+ HgpWrc3ZSWGcO9eBpIBqH4Q3G7LE82wNgM63qmDMyfKh/E1SkJviFFeuDKaqwkc7sqw6 iLzRv8iDnWTSRilhtvd8opqNEpppG8g2mzZmaxDYLF3a7fV9LYcqSaJpxeIf4CBL+y0U pODQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=btao10aRBJQ28UG/WT4Ks5mnqE9nwQw1aiHAe1lV7dE=; b=iwGOa/E3fNXuCRf1Qa451we3zfdbYT7IhGTjp/zklDYknwDhRHNl2asAV5e5eDPVkl l9N3AN+GellpHMib+cXsL/3zfX9quGKY6uSuV0pSutJm5FYCA0HDjIBMv0NXWk3+TQZl hpiYtJw8J4WoYyDOf3zFhQ4y9InKIRi6GBV66SdLARf+Jt39uVk0XWYs9H8d186qxHIb tnXa1wOc04cWEFbUjk+HAYNQDiuHXsugSILNSvvblQ8/sCB74wcTpKpiDuR+aDJs9RuI ku4YuFc6s3RB8GdXkgZOU3AS/fEK3fjWEWPqmkRhRg6zT479+WyOAt92YqtibS0JPw1r +AUQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 130si39905066pgc.256.2019.05.01.20.05.21; Wed, 01 May 2019 20:05:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726197AbfEBDFU (ORCPT + 99 others); Wed, 1 May 2019 23:05:20 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:44140 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726183AbfEBDFU (ORCPT ); Wed, 1 May 2019 23:05:20 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92 #3 (Red Hat Linux)) id 1hM210-0001NK-Lx; Thu, 02 May 2019 03:04:06 +0000 Date: Thu, 2 May 2019 04:04:06 +0100 From: Al Viro To: Wenbin Zeng Cc: davem@davemloft.net, bfields@fieldses.org, jlayton@kernel.org, trond.myklebust@hammerspace.com, anna.schumaker@netapp.com, wenbinzeng@tencent.com, dsahern@gmail.com, nicolas.dichtel@6wind.com, willy@infradead.org, edumazet@google.com, jakub.kicinski@netronome.com, tyhicks@canonical.com, chuck.lever@oracle.com, neilb@suse.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-nfs@vger.kernel.org Subject: Re: [PATCH 1/3] nsfs: add evict callback into struct proc_ns_operations Message-ID: <20190502030406.GT23075@ZenIV.linux.org.uk> References: <1556692945-3996-1-git-send-email-wenbinzeng@tencent.com> <1556692945-3996-2-git-send-email-wenbinzeng@tencent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1556692945-3996-2-git-send-email-wenbinzeng@tencent.com> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Wed, May 01, 2019 at 02:42:23PM +0800, Wenbin Zeng wrote: > The newly added evict callback shall be called by nsfs_evict(). Currently > only put() callback is called in nsfs_evict(), it is not able to release > all netns refcount, for example, a rpc client holds two netns refcounts, > these refcounts are supposed to be released when the rpc client is freed, > but the code to free rpc client is normally triggered by put() callback > only when netns refcount gets to 0, specifically: > refcount=0 -> cleanup_net() -> ops_exit_list -> free rpc client > But netns refcount will never get to 0 before rpc client gets freed, to > break the deadlock, the code to free rpc client can be put into the newly > added evict callback. > > Signed-off-by: Wenbin Zeng > --- > fs/nsfs.c | 2 ++ > include/linux/proc_ns.h | 1 + > 2 files changed, 3 insertions(+) > > diff --git a/fs/nsfs.c b/fs/nsfs.c > index 60702d6..5939b12 100644 > --- a/fs/nsfs.c > +++ b/fs/nsfs.c > @@ -49,6 +49,8 @@ static void nsfs_evict(struct inode *inode) > struct ns_common *ns = inode->i_private; > clear_inode(inode); > ns->ops->put(ns); > + if (ns->ops->evict) > + ns->ops->evict(ns); What's to guarantee that ns will not be freed by ->put()? Confused...