Question on mmap / expecting more calls to vfs_read

[fs.rajat@gmail.com (Rajat Sharma)]

I meant 'file holes' not 'wholes' in last mail... my bad in shooting mails
:(

Rajat

On Fri, Jan 7, 2011 at 11:56 AM, Rajat Sharma <fs.rajat@gmail.com> wrote:

> > Add your stats hooks to do_mmap or mmap_region() ???
>
> mmap is one time call to initialize virtual address space of current
> process with corresponding region on file's disk image. Once this setting is
> done, this the actual calls to read data from file is accomplish through
> memory area's (vma) page fault handlers which in turn call readpage address
> space operation of an inode:
>
> inode->i_mapping->a_ops->readpage(file, page).
>
> so, suitable position is to add hooks on readpage a_op. And of-course for
> doing that, you may have to capture various path thorugh which inode can
> come in memory, e.g. lookup and create directory inode operation (for
> regular files). For your worst nightmare, NFS implements its readdir with an
> additional feature with v3 protocol called READDIR PLUS, which not only
> gives you name of children of a directory, but also initializes their inodes
> in memory, so you may have to hook readdir as well and trap aops of all
> regular file child after nfs_readdir is finished.
>
> As far as offset and length of I/O are concerned, page->index gives you its
> index in the page cache which in turn is equivalent to file offset
> (page->index << PAGE_SHIFT). readpage is invoked to bring in complete page
> in memory. It may so happen that page is a partial page (e.g. last page of
> file), in that case your I/O lenght will be inode->i_size & ~PAGE_MASK,
> otherwise it can be PAGE_SIZE. don't worry about file wholes, that is taken
> care by filesystem's original readpage method.
>
> Having said above, it will still be better if you can state what you want
> to achieve in little layman language.
>
> Rajat
>
>
> On Fri, Jan 7, 2011 at 5:39 AM, Manish Katiyar <mkatiyar@gmail.com> wrote:
>
>> On Thu, Jan 6, 2011 at 3:49 PM, Sebastian Pipping <sebastian@pipping.org>
>> wrote:
>> > On 01/06/11 07:53, Rajat Sharma wrote:
>> >> Hi Sebastian,
>> >>
>> >> you guess for ELF header seems to be valid to me. When executables or
>> >> binaries are loaded memory, it is done through mmap call to the file,
>> >> and to understand what file is and what binary handler in kernel can
>> >> handle its section, kernel needs to know its header first, which is
>> >> within the first page of the header with fixed location for a magic
>> >> number (identifier for binary handler e.g. ELF handler which further
>> >> loads its other sections by reading section table). Note that there
>> >> are multiple binary format handles within the kernel e.g. ELF, A.OUT
>> >> which are tried sequentially to identify the file format.
>> >>
>> >> From the file system perspective, mmap does not use vfs_read or
>> >> vfs_write calls at all, thats why you don't see them. It directly
>> >> works on address space operations of an inode (file) to populate data
>> >> in page-cache. For a mmapped region, if you don't see a page in
>> >> memory, kenel page faults and tries to read-in the page using readpage
>> >> method of address_space_operations. Similarly when you modify a page,
>> >> writepage method is called, but since executables are accessed
>> >> read-only, you won't see writepage method getting called either.
>> >>
>> >> Hope this makes it clearer.
>> >
>> > Excellent, thank you!  I find calls to readpages on file
>> > /lib/libc-2.11.2.so now.  That may be the missing reads.
>> >
>> > Any ideas how get offset and length (like with vfs_read) for a certain
>> > page passed to readpage(file, page) ?
>>
>> Add your stats hooks to do_mmap or mmap_region() ???
>>
>> --
>> Thanks -
>> Manish
>> ==================================
>> [$\*.^ -- I miss being one of them
>> ==================================
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110107/2216691d/attachment-0001.html