Some Kernel Questions/Confusions [Pls help]

[Er Krishna]

Hi All,

Pls help me here by answering following two queries. If my understanding is
incorrect in asking the question pls correct me:


1. In case of Paging and discontiguous memory allocation for a particular
process, is it possible that all the segments say DS, SS, CS, Heap and all
can be in different page frames. I am asking this for a particular segment
(I know all the segments can be in different non contiguous pages
seperately, but what about one segment in different non contiguous page
frames). For example lets say stack segment (or data segment) which is in
RAM requires 45 pages and in RAM 45 pages are not contiguous avilable, so
can it be reside from page frame no 100-125 and then again in 140-160  ?


2. In case of execution of  fast interrupt handler when other interrupts
are disable, if device controller generate interrupt then it will not
reaches to CPU ? Is it loss of interrupts and not a good condition on
system/driver ? Can we ignore it safely for our driver or we must not fall
into this scenario ?


3. Inside kernel page fault should not happen, I was trying to understand
it w.r.t copy from/to usr api. Say on usr address the particular page is
not there and kernel wants to copy it in kernel address space? What will
happen if we use memcpy rather than copy from usr, will the kernel crash
due to page fault? how copy from usr prevents this? Is the page fault
handler code always remains in RAM in case of  Linux Kernel ?


4. In case of read/write system call, a normal user program wants to acess
some file or more specifically (direct or indirect block of particular
inode). This user space process page table which is in RAM doesn't contain
valid bit for particular pages which correspond to these blocks. If these
blocks are not in page-cache, it will be bring ito RAM by vector i/o with
the help of bio-vec data structures. Will this scenario triggers the page
fault inside kernel ?


Best Regards,
Krishna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141027/9bf8f54a/attachment.html