From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leonid Fedorenchik Subject: Re: help with understanding evict inode functionality Date: Fri, 2 Oct 2015 16:57:10 +0300 Message-ID: <560E8D36.7010803@paragon-software.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "linux-fsdevel@vger.kernel.org" To: "Kornievskaia, Olga" Return-path: Received: from relaymsk-01.paragon-software.com ([91.226.210.14]:64385 "EHLO relaymsk-01.paragon-software.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752128AbbJBOFf (ORCPT ); Fri, 2 Oct 2015 10:05:35 -0400 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, 1 Oct 2015 22:54:08 +0000 "Kornievskaia, Olga" wrote: > [...] > > In NFS development, we=C3=A2=C2=80=C2=99ve been seeing a race between= reopening of the same file and evict inode code and unable figure out = how to prevent such race. When file is opened for the first timed and t= hen closed. As the last reference is dropped and iput_final() calls evi= ct() which will call filesystem specific evict_inode() code. As that=C3= =A2=C2=80=C2=99s happening a new open for the same file is happening an= d causes problems. Recently we encountered similar situation with NFS, that is, after evict_inode() & iget_locked() we were getting the same inode (same i->i_ino) and without I_NEW bit set. > > Also can somebody suggest how to debug VFS code, as putting printks g= enerates output for the local filesystem code as well. You can call printk() only if current process is "nfsd" (at least, that is what we did). > > Thank you. > > [...] --=20 Best regards, Leonid Fedorenchik Software Engineer Paragon Software Group Skype: leonid.fedorenchik http://www.paragon-software.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html