Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1054401pxk; Fri, 18 Sep 2020 02:38:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwkiIl8jGhPy8O/uO6FF4fOnlVecflBZVPjqKE20ikPgRGPS9E619TXso6vKAyIhWEK8Ql2 X-Received: by 2002:a17:906:594c:: with SMTP id g12mr36165764ejr.347.1600421935332; Fri, 18 Sep 2020 02:38:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600421935; cv=none; d=google.com; s=arc-20160816; b=nW6PV+iNNm/nm0FZRJ4XYFGOe3jr/U0JiW1/1ro2LQQyDMQc6eIJJ30d+CN+JgO3Ra fHkq1LQAgx+CwJekYO2M9Y1s3FBt6hYmKjGrGBNEzGFK1Tg5zn2x501Oftiuh0q+cFl8 CJTuFgcOPcN9NOJ+hFqWhVaWZ9lRzw2bB5YL6IWuu0pWyOX6cHR/VoIIThvMiddIIaBZ R00OSVc2AL5QsB4GtEbqpcxVXCviwZ5CPos8fN7Txkj6V3JSKQNmPC73CKRIB2g48szx GxYK9qDtrImOll9/546bEwR/YNftHF6HVGSesTlJtyPeBFLB1b+kmSbCoChGBKUWlsnB FsKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=lmSsSvV/eUyk83KxPgQ2WexenH8e0Ixm8xd3pHKJsGM=; b=Ki7DdAavRj6tp2pXnLdUqBqCMtI8oT/iUYLjgVMfnIy0F97ecXvYmOd6LCFYHWPvrM h//b/XekUgj4jdH0EtFWOTeqplOSx0CT7se/wPtdBW4hdBRTSZ6DDsvBeA75aENZNwMm H4H1+Os6pgV3zU1BSVRoFn94VOBv7BCEJWrwHxP0a0Ij092wCE6/MwiKIr1ZGMUClXfd cD5fL9pgPmNZKwX9ctCPSnKQ1LHLJBH0VjXpwLZvpKS0H51QiZcO3AT30krY3RtbE/WZ Tm3INGrXFVKQTGx+cgt0V0IkZWqJ3PqkJ6j+7Gni0HHQN0pqZCbgeOtGNRrVWTRywpfd pi0g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gl12si1782991ejb.337.2020.09.18.02.38.31; Fri, 18 Sep 2020 02:38:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726306AbgIRJe5 (ORCPT + 99 others); Fri, 18 Sep 2020 05:34:57 -0400 Received: from nautica.notk.org ([91.121.71.147]:47793 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726109AbgIRJe5 (ORCPT ); Fri, 18 Sep 2020 05:34:57 -0400 X-Greylist: delayed 12920 seconds by postgrey-1.27 at vger.kernel.org; Fri, 18 Sep 2020 05:34:56 EDT Received: by nautica.notk.org (Postfix, from userid 1001) id 62839C01D; Fri, 18 Sep 2020 11:34:55 +0200 (CEST) Date: Fri, 18 Sep 2020 11:34:40 +0200 From: Dominique Martinet To: Jianyong Wu Cc: "ericvh@gmail.com" , "lucho@ionkov.net" , "v9fs-developer@lists.sourceforge.net" , "linux-kernel@vger.kernel.org" , Justin He , Greg Kurz Subject: Re: [PATCH RFC 4/4] 9p: fix race issue in fid contention. Message-ID: <20200918093440.GA1877@nautica> References: <20200914083200.GA9259@nautica> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jianyong Wu wrote on Fri, Sep 18, 2020: > If we move the counter decrease code into p9_client_clunk and put it > instead of fid_atomic_dec, we need delete fid off the inode where it > stores in p9_client_clunk. > But there is no way can we acquire the inode in p9_client_clunk. Do > you have any idea? I think introduce another parameter for > p9_client_clunk > Is not graceful. You cannot write code about the inode in p9_client_clunk, the way the code is split fs/9p can refer to net/9p but not the other way around (module-wise, 9p can refer to 9pnet but 9pnet cannot refer to 9p or we would have cyclic dependencies) However I don't see what bothers you. v9fs_dir_release can remove the fid from the inode as it does currently and just clunk immediately afterwards. If another user of the fid had gotten the fid from the inode previously, it has a ref, so the fid will not be actually clunked then but it will be clunked later when it is done being used -- that is perfectly fine ? p9_client_clunk should not have to worry about anything in the vfs. -- Dominique