Re: Accessing file mapped data inside the kernel

[Paulo da Silva <psdasilva@esoterica.pt>]

Anton Altaparmakov wrote:

>On Thu, 10 Nov 2005, Paulo da Silva wrote:
>  
>
>>Anton Altaparmakov wrote:
>>    
>>
>>>On Wed, 9 Nov 2005, Paulo da Silva wrote:
>>>      
>>>
>>>>I posted about this a few days ago but got no responses
>>>>so far! I think this should be a trivial question for those
>>>>involved in the kernel internals. May be I didn't develop
>>>>the problem enough to be understood.
>>>>
>>>>So, here is the question reformulated.
>>>>
>>>>A given file system must supply a procedure for mmap.
>>>>
>>>>int <fsname>_file_mmap(struct file * file, struct vm_area_struct * vma)
>>>>{
>>>> int addr;
>>>> addr=generic_file_mmap(file,vma);
>>>> <Code to access addr pointed bytes or vma->vm_start>
>>>> return addr;
>>>>}
>>>>
>>>>I could verify that "addr" is what is returned to the user as
>>>>a pointer to a string of bytes that maps a file when a user
>>>>program calls mmap or mmap2.
>>>>
>>>>In the user program, I can access those bytes (read/write)
>>>>as, for ex., a char pointer.
>>>>
>>>>I don't know how to access those bytes inside the kernel
>>>>at the point <Code to access addr pointed bytes or vma->vm_start>
>>>>
>>>>First trys led the program that invoked mmap to block.
>>>>I thought that there's something to do with a previous
>>>>  down_write(&current->mm->mmap_sem);
>>>>If I execute
>>>>  up_write(&current->mm->mmap_sem);
>>>>before accessing the data the block situation does not
>>>>occur anymore. I would like to hear something about
>>>>this.
>>>>
>>>>Anyway, I tryed to use "copy_from_user" but I got
>>>>garbage, not the file contents! Using "strncpy" crashes
>>>>the kernel (UML)!
>>>>
>>>>Can someone please write a fragment of code to safely
>>>>access those bytes, copying them to and from a
>>>>kernel char pointed area so that they are read/written
>>>>to the file?
>>>>        
>>>>
>>>Why do you want to do that?  If you explain what you are trying to do it may
>>>be possible to help you better.  It is almost 100% certain that your are
>>>going about it in completely the wrong way, so please describe what you are
>>>trying to do...
>>> 
>>>      
>>>
>>Just try to understand the kernel filesystem.
>>So far I could understand the 1st layer of
>>reading and writing. mmap seems to be a
>>difficult task however. So, I made a 1st try
>>looking at mmap supplied by the filesystem,
>>but I couldn't even succeed with a printk
>>of the mapped area! I would like to understand
>>what is the meaning of the address (int) returned
>>by generic_file_mmap that is also into vma->vm_start
>>and is returned to the user as a char pointer.
>>I thought that this address, being accessible
>>by a user program as a char pointer, should also
>>be accessible by a copy-from-user inside the
>>kernel. Unfortunately, this didn't happen!
>>Why? That's my question. Did I make any mistake?
>>A basic fragment of code showing how to access
>>that area could enlight me so that I could go
>>deeply into the code.
>>
>>Ex.
>>Suppose a file has a string of text ("foo")
>>and the user calls mmap.
>>
>>Why does this code not work?
>>
>>The supplied filesystem mmap is "generic_file_mmap".
>>So, I changed it to foo_file_mmap as follows:
>>
>>int foo_file_mmap(struct file * file, struct vm_area_struct * vma)
>>{
>>
>> int addr;
>> char tstr[100];
>> addr=generic_file_mmap(file,vma);
>> up_write(&current->mm->mmap_sem); /* Without this the user program is dead
>>locked */
>> copy_from_user(tstr,(char*)addr,4);
>> printk("%s",tstr);
>>
>> return addr;
>>}
>>    
>>
>
>That's what I thought.  You are doing completely the wrong thing.  mmap() 
>does not read anything, it just creates the page tables.  Only after that, 
>when the user tries to access the memory, does a page fault occur (because 
>the page does not exist) and the page fault handler kicks in which leads 
>to the file system's ->readpage() being called which fills the accessed 
>page with data.  Subsequent accesses to the same address (or any other 
>address belonging to the same page) are direct memory accesses.  When the 
>user tries to access an address outside the page, another page fault 
>occurs and the page corresponding to the new address is faulted in, etc...
>
>So what you are trying to do makes no sense from a kernel point of view at 
>all.  If you want to read page cache data in the kernel (this is what you 
>are actually trying to do but going about it in the wrong way), you want 
>to use read_cache_page(), then kmap() or kmap_atomic() of the page, then 
>access the data, then kunmap() or kunmap_atomic(), then finally 
>page_cache_release().
>
>  
>
Thank you for your explanation! Things are becoming more
clear now ...
I thought of something like that before - not so elaborated ...
but I became confused because the "page fault" could occur
also at the point I referred. However, today I saw that there is
more "processing" in do_mmap_pgoff after filesystem xxx_file_map
gets called. I have to look at this ... My next step.

BTW, why isn't there a full comented template about filesystems?
Every examples and docs I found are from k 2.4.x! May be someone
could rewrite them for 2.6 and in some cases add the lacking mmap.

Thank you.
Paulo