Some Kernel Questions/Confusions [Pls help]

[Valdis.Kletnieks at vt.edu]

On Mon, 27 Oct 2014 18:15:15 +0530, Er Krishna said:

> 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  ?

Yes.  In fact, it *probably* ends up in frames 97, 215, 112, 438, etc etc - the
kernel doesn't try too hard to keep them contiguous unless something specifically
requests contiguous allocation.

> 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 ?

In general, losing interrrupts isn't a good idea.  Whether it's acceptable
for your driver or not will depend on your hardware, and basically depends
on the answer to the question "What does your hardware do if it requests
an interrupt, and it decides it needs another interrupt before the first
one has been serviced?"  Some devices are stupid, and totally lose the
plot if this happens - others are smarter and can either coalesce the
interrupts or just ask again after then first one has been serviced.


> 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 ?

Copy from user basically checks for the page's availability first, and requests
a page in, and then waits for the page to arrive, to avoid the nasty mess
of taking a page fault inside the 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 ?

I'll leave this one for you to figure out. It's not that hard. (Hint - in the
code path you describe, why would any of those steps cause a page fault?)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141027/97d34750/attachment-0001.bin