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
