On Wed, Oct 21, 2009 at 7:39 AM, Joel Fernandes <agnel.joel@xxxxxxxxx> wrote:
Hi Rajat,
Hi,
Let me put my inputs on this,
So kernel virtual memory is always directly and permanently mapped and
never has to fault? Is this for performance or is it because the
kernel can't handle its own faults (kernel doesn't want to take
responsibility for its own faults!).
Yes, kernel virtual memory (memory for kernel text segment,...) upto 896MB of virtual memory is permanently mapped. Its not a perfomance related, suppose if a physical memory page containig code for page fault handler is allowed to swapped out then what .... we are gone .. So kernel code is always residednt in RAM and never swapped out.
Also I would be grateful if you could describe in a sentence or two,
how this copy from user to kernel space happens? my guess - it looks
up the process's mm_struct and gets the physical location of its pages
whether on disk or in physically memory, and then makes a copy of it
to kernel space? wouldn't this be slow if the user memory is still on
disk?
No, cpoy_to_user/copy_from_user (in x86..) is a simple memcpy operation with a extra code for creating an entry in exception table. Now why this.. copy_to_user may cause page fault (if page to which we need to copy data is not in memory), in page fault handler it check exception table entries and if current page fault is because of copy_to_user/from_user then requested page is loaded into memory and code start normally.
All address checking is done by MMU in hw (x86)
Also at the time copy_from_user is called, it seems the memory would
be uptodate anyway and going to disk wouldn't be required. The user
obviously stored something in the memory and the processor would have
segfaulted already?
Segfault will kill the user space program, but if page fault originated from kernel code is not handled then system stability is at risk. Thats the main reason copy_to_user and copy_from_user are implemented to create an entry in exception table to capture any invalid memory pointer being passed from user space application.
thanks,
-Joel
On Tue, Oct 20, 2009 at 4:08 AM, Rajat Jain <Rajat.Jain@xxxxxxxxxxxx> wrote:
>
> Hi,
>
>> Thank you for your reply.
>> it's interesting, my modified kernel image is run ok on my
>> hardware(arm926ejs). i test mounting ramfs and nfs, they are all ok.
>> are they occasional?
>>
>> sorry, i don't comprehend your explanation about it
>> In my opinion, if it's possible that the content of
>> parameters isn't in memory at the time of the call, the
>> "sys_mount" can't get them also.
>>
>> could u explain it in detail? Thanks
>
> OK. So here is it. Not all memory used by user space actually needs to
> be in RAM all the time. It may be swapped out to disk since the actual
> memory in use in a system is much more than its RAM size. When a piece
> of memory that is currently swapped out on disk needs to be accessed, it
> needs to be brought back into RAM memory - this is done by the page
> fault handler. But consider that the Disk IO is a very slow process, and
> thus it is relatively a very huge time for the kernel. For this reason,
> any memory that is accessed by the kernel needs to be locked down in RAM
> so that it cannot be swapped out.
>
> Secondly, the 4GB virtual address space is split up into user space and
> kernel space code (3G/1G split generally). User space cannot access
> kernel space virtual addresses and vice versa. Thus the user space
> pointer cannot be dereferenced in the kernel.
>
> Thus, any user data that needs to be accessed firstly needs to be copied
> into kernel address space. This done generally by copy_from_user()
> function or its varians that sys_mount() uses:
>
> exact_copy_from_user((void *)page, data, size);
> strncpy_from_user(page, filename, len);
>
> Now, how you code works comes as a surprize to me though...
>
> Thanks,
>
> Rajat
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>
Hope this help ...
Thanks,
Chetan Nanda
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
