From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shaya Potter Subject: Re: which dentry a page belongs to Date: Fri, 23 Apr 2004 11:42:19 -0400 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <1082734938.1943.26.camel@zaphod> References: <1082732223.1943.11.camel@zaphod> <20040423151458.GC6300@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from opus.cs.columbia.edu ([128.59.20.100]:19604 "EHLO opus.cs.columbia.edu") by vger.kernel.org with ESMTP id S264849AbUDWPm2 (ORCPT ); Fri, 23 Apr 2004 11:42:28 -0400 To: Jamie Lokier In-Reply-To: <20040423151458.GC6300@mail.shareable.org> List-Id: linux-fsdevel.vger.kernel.org On Fri, 2004-04-23 at 16:14 +0100, Jamie Lokier wrote: > Shaya Potter wrote: > > It would seem that since the > > address_space object contains the vm_area_struct's of i_mmap and > > i_mmap_shared I should then be able to get the appropriate file and > > dentry object's through > > > > page->mapping->i_mmap->vm_file->f_dentry > > > > or > > > > page->mapping->i_mmap_shared->vm_file->f_dentry > > > > 1) Is this correct logic? I'm assuming the only things that matters in > > choosing which list is used if the page is map'd shared or not? is that > > correct as well? > > No, no and no. > > i_mmap and i_mmap_shared are lists. They can both be empty, or both > non-empty. A page can be mapped shared *and* non-shared at the same > time. A page might not be mapped at all. yes, they can be empty for "generic" pages, but I'm looking at a specific case of file system pages, so they shouldn't be empty. i.e. otherwise my fs's writepage() shouldn't be called, I would think. > Also, a page is often mapped in a _subset_ of the mappings which are > found in i_mmap and i_mmap_shared: it depends on its offset, and the > vma offsets, and non-linear mapping offsets. ok, this I don't understand. need to look into this, so it's not as simple a dereference as I thought. > It is possible to find multiple dentries which are currently being > used to map a page. a single page can have multiple dentries? but it has only one inode? (i.e. host) So I can imagine if the single inode is linked in multiple places (for my purposes I don't care about that directly) but can it really have multiple inodes? > It's also possible to find no dentries at all. even if in my fs's writepage() function? > Your question is extremely ill-formed. What do you mean by "the > dentry corresponding to a page"? What do you want the value for? When my writepage() is called, I want to be able to possibly do dentry based operations (rename, d_path....) to be told what files are actually getting written to via writepage() (as opposed to the file system's write() functionality). i.e. there are 2 ways for a file to be written to a file system (at least as far as I understand, could easily be wrong) writepage() and write(). in write() one know's the dentry (file->f_dentry) I'm trying to figure out how I can get the same knowledge for writepage() from the page passed to it.