Messages in this thread | | | Date | Fri, 18 Dec 2009 15:33:30 +0900 | From | Minchan Kim <> | Subject | Re: [RFC 4/4] speculative pag fault |
| |
On Fri, 18 Dec 2009 15:06:48 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Fri, 18 Dec 2009 14:54:49 +0900 > Minchan Kim <minchan.kim@gmail.com> wrote: > > > Hi, Kame. > > > Hi, > > > On Fri, 18 Dec 2009 09:46:02 +0900 > > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > > > > if (flags & FAULT_FLAG_WRITE) { > > > if (!pte_write(entry)) > > > > > > > I looked over the patch series and come up to one scenario. > > > > CPU A CPU 2 > > > > "Thread A reads page" > > > > do_page_fault > > lookup_vma_cache > > vma->cache_access++ > > "Thread B unmap the vma" > > > > mm_write_lock > > down_write(mm->mmap_sem) > > mm->version++ > > do_munmap > > wait_vmas_cache_access > > wait_event_interruptible > > mm_version_check fail > > vma_release > > wake_up(vma->cache_wait) > > unmap_region > > mm_write_unlock > > mm_read_trylock > > find_vma > > !vma > > bad_area > > > > As above scenario, Apparently, Thread A reads proper page in the vma at that time. > > but it would meet the segment fault by speculative page fault. > > > Yes, It's intentional. > > > Sorry that i don't have time to review more detail. > ya, take it easy. I'm not in hurry. > > > If I miss something, Pz correct me. > > > > In multi-threaded application, mutual-exclusion of memory-access v.s. munmap > is the application's job. In above case, the application shouldn't unmap memory > while it's access memory. (The application can be preempted at any point.) > So, the kernel only have to take care of sanity of memory map status. > In this case, no error in kernel's object. This is correct.
Ahhh. It's my fault. I need sleeping. :) After take a enough rest, I will review continuosly.
Thanks. Kame.
> Thank you for your interests. > > Regards, > -Kame > > > > >
-- Kind regards, Minchan Kim
| |