From mboxrd@z Thu Jan 1 00:00:00 1970 From: Livio Baldini Soares Subject: Race with inodes in I_FREEING state Date: Fri, 13 Jun 2003 00:44:45 -0300 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20030613034445.GA8074@ime.usp.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: neilb@cse.unsw.edu.au Return-path: Received: from birosca.ime.usp.br ([143.107.45.59]:23223 "HELO birosca.ime.usp.br") by vger.kernel.org with SMTP id S265116AbTFMDbB (ORCPT ); Thu, 12 Jun 2003 23:31:01 -0400 To: linux-fsdevel@vger.kernel.org Content-Disposition: inline List-Id: linux-fsdevel.vger.kernel.org Hello! I'm developing a file system for Linux (I'm currently only using the 2.4 tree), and have seem to have hit a small race with the VFS code starting to iget() an inode while it's being freed, which is causing my code to panic. The race occurs in the following scenario: 1) prune_icache() is called, and inode $x$ (ino = $z$) is removed from the inode hash. 2) dispose_list() is called, but is preempted/scheduled. 3) Another task calls iget() for inode $y$ (ino also = $z$), doesn't find it in the hash, and reads the inode (read_inode()). 4) dispose_list() wakes up, and finally calls FS-specific clear_inode() operation on inode $x$. It _is_ true that $x$ on steps 1 and 4 is a different inode than $y$ in step 3. However, my FS has some hashed/shared data, kept in 'union u', which is deleted when clear_inode() is called. So, in the end of step 4, inode $y$ has a broken 'u' field, pointing to deleted memory. After looking around in the archive, I believe this race is similar to the one described here, by Niel Brown: http://marc.theaimsgroup.com/?l=linux-kernel&m=105235852013658&w=2 Does this not also happen in version 2.4.20? Can anybody tell me if my logic is wrong, or if I'm just plain doing something stupid in my FS? Hope I have not troubled anyone, best regards, -- Livio B. Soares