On Wed, Jul 23, 2008 at 6:55 AM, Rik van Riel <riel@xxxxxxxxxxx> wrote: > On Tue, 22 Jul 2008 23:28:01 +0200 > ninjaboy <n0b0dyn1nj4@xxxxxxxxx> wrote: >> 2008/7/22 Rik van Riel <riel@xxxxxxxxxxx>: >> > On Tue, 22 Jul 2008 13:51:43 -0400 >> > Arn <cse.syslab@xxxxxxxxx> wrote: >> > >> >> So I assume that when a major fault happens, somehow get_user_pages() >> >> gets called, is that correct ? >> > >> > No. When a page fault happens, handle_mm_fault() is called. >> > >> > The get_user_pages() path is when kernel code tries to access >> > the pages of a process that is not the current process. >> > >> >> why kernel tries to access the page of a process that is not the >> current process? > > Think about attaching a debugger to a userspace process and > trying to peek or poke the memory of the process. > > The debugger may try to access memory that is currently > swapped out, which will cause the memory to get swapped in. > Is this the only scenario that can happen? Another variation is process context vs interrupt context - but then I think it should never happen. CPU may be running in process A context, when suddenly it got interrupted by a hardware event. And within the interrupt handler it may attempt to update "userspace" structures (eg, userspace memory) belonging to process B. This scenario should never happen - right? (because userspace memory are swappable, and thus accessing it may block). But then accessing kernel structures belonging to process B should be alright.......for this I cannot think of any possible example.....except perhaps the unlikely scenario of the kernel sharing its kernel memory via mmapping it to userspace. In particular scenario, when the NIC card gets returned results, running in edge-triggered interrupt mode, it should be updating kernel structures - right? And then the process will poll this kernel buffer for returned results. It should not be getting results directly from the interrupt handler. Correct? Thank you Rik and everyone for sharing/discussion, enjoy your day :-). -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
