From mboxrd@z Thu Jan 1 00:00:00 1970 From: Priya Kamala Subject: Correct way to handle an error condition in inode lookup Date: Tue, 07 Jan 2014 13:04:44 +0000 Message-ID: <52CBFB6C.3040103@perpetual-data.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: Linux FS Devel Return-path: Received: from deferred-out-118.livemail.co.uk ([213.171.216.118]:44395 "EHLO deferred-out-118.livemail.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750904AbaAGN3W (ORCPT ); Tue, 7 Jan 2014 08:29:22 -0500 Received: from cust-smtp-192.fasthosts.net.uk (smtp-out-60.livemail.co.uk [213.171.216.60]) by deferred-out-118.livemail.co.uk (Postfix) with ESMTP id CABD95A9AA3 for ; Tue, 7 Jan 2014 13:04:59 +0000 (GMT) Received: from [192.168.2.3] (host90-152-39-95.ipv4.regusnet.com [90.152.39.95]) by cust-smtp-192.fasthosts.net.uk (Postfix) with ESMTP id AFBE5770173 for ; Tue, 7 Jan 2014 13:04:48 +0000 (GMT) Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi all, I am working on a linux filesystem filter driver used for archiving. The filter is layered on top of xfs. We are currently trying to implement a feature to incrementally recover a filesystem, in other words repopulate a directory on-the-fly. During initial recovery only the root directory is populated. Other directories get populated when they are accessed for the first time. To rebuild a directory the filter has to temporarily unlock the directory inode's i_mutex. This does mean that other requests can come in at the same time resulting in the following condition. I launch two threads simultaneously. Thread 1 lists and deletes the contents of a folder and finally the folder itself, while Thread 2 renames the first file in the same folder. Thread 1 Thread 2 ------------ ------------ readdir release i_mutex to rebuild dir acquire lock A to rebuild dir rebuild offline dir starts lookup file.0 release i_mutex to rebuild dir acquire lock A to rebuild dir rebuild dir completes acquire i_mutex mark directory online release lock A no need to rebuild as directory has been populated by Thread 1 revalidate file.0 unlink file.0 acquire i_mutex release lock A lookup returns valid dentry with inode created during Thread 1 rebuild rename file.0 (Crashes with "Internal error xfs_trans_cancel at line 1925 of file fs/xfs/xfs_trans.c") evict_inode destroy_inode Right now I'm using d_unlinked to check if a valid d_entry has been unlinked. I've tried using d_delete if the file has been unlinked, but this will fail if there is a third thread trying to stat the same file and lookup will return a valid d_entry causing rename to crash. What is the correct way to detect that a file has been unlinked but the inode hasn't been destroyed yet in the lookup function and how should this be handled? I am working with kernel version 3.2.52. Let me know if you need additional information. If this is not the correct forum for this question, please point me in the right direction. Thanks, Priya