From mboxrd@z Thu Jan 1 00:00:00 1970 From: Badari Pulavarty Subject: Re: eCryptfs: Request for review Date: Wed, 19 Oct 2005 14:38:35 -0700 Message-ID: <1129757915.8716.29.camel@localhost.localdomain> References: <20051018193811.GA11545@halcrow.us> <1129736164.25733.19.camel@polarbear.fsl.cs.sunysb.edu> <1129750686.29319.7.camel@polarbear.fsl.cs.sunysb.edu> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: "Charles P. Wright" , Michael Halcrow , linux-fsdevel@vger.kernel.org Return-path: Received: from qproxy.gmail.com ([72.14.204.205]:62228 "EHLO qproxy.gmail.com") by vger.kernel.org with ESMTP id S1751365AbVJSVjN (ORCPT ); Wed, 19 Oct 2005 17:39:13 -0400 Received: by qproxy.gmail.com with SMTP id v40so193860qbe for ; Wed, 19 Oct 2005 14:39:11 -0700 (PDT) To: Michael Thompson In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, 2005-10-19 at 14:55 -0500, Michael Thompson wrote: > On 10/19/05, Charles P. Wright wrote: > > The reference count of an eCryptfs dentry may not be the same as the > > reference count of the lower-level dentry. If the eCryptfs dentry hits > > zero, but the lower-level dentry does not, you are going to remove the > > lower-level dentry from the name space prematurely. > > > > This manifested itself on Unionfs running over squashfs. > I C, if you will. Now that I know, consider it removed :) > > > > > In ecryptfs_llseek, If you are adding pages for extra information, you > > > > need to convert the offset to a lower-level offset, and then convert the > > > > return back to what user space expects it to be. You should test fsx on > > > > your file system, to sort these types of things out. > > > I believe that this is working, we have run fsx "succesfully" for > > > 10000 iterations. However, its not a total success because we are > > > bugging out in fs/buffer.c:1822 BUG_ON(PageWriteback(page)); > > > Will look a bit more closely though. > > Actually nevermind, you are using generic_file_llseek on your own file > > instead of passing the operation down. That should be fine and dandy > > for files, but I don't know if you are going to have problems with > > directories. > Guess I'll have to test a bit more then... *marks on the TODO*. > > Would you like to take a stab at why we are hitting the > fs/buffer.c:1822 BUG_ON(PageWriteback(page)); problem? > I'm pretty much at a loss, although, I will be honest, I haven't > looked into it very much It is telling you that there is already IO in progress on that page. Either you ended up in __block_write_full_page() twice or called __block_write_full_page() before finishing up end_page_writeback(). Thanks, Badari