On Tuesday 16 May 2006 16:09, Dave McCracken wrote: > --On Monday, May 08, 2006 14:32:39 -0500 Ray Bryant > > wrote: > > On Saturday 06 May 2006 10:25, Hugh Dickins wrote: > > > > > >> How was Ray Bryant's shared,anonymous,fork,munmap,private bug of > >> 25 Jan resolved? We didn't hear the end of that. > > > > I never heard anything back from Dave, either. > > My apologies. As I recall your problem looked to be a race in an area > where I was redoing the concurrency control. I intended to ask you to > retest when my new version came out. Unfortunately the new version took > awhile, and by the time I sent it out I forgot to ask you about it. > > I believe your problem should be fixed in recent versions. If not, I'll > make another pass at it. > > Dave McCracken > Dave, I'm sending you a test case and a small kernel patch (see attachments). The patch applies to 2.6.17-rc1, on top of your patches from 4/10/2006 (I'm assuming these the most recent ones.). What the patch does is to add a system call that will return the pfn and ptep for a given virtual address. What the test program does (I think :-) ) is to create a mmap'd shared region, then fork off a child. The child then re-mmaps() private a portion of the region. Call it without arguments for now, that should map 512 pte's and share them between the parent and 1 child. [Later on we can try more pages and more children. (e. g. ./shpt_test1 128 64).] At this point, what I expect to have happened is that in at the shared region address in the child, there will be a number of pages that are still shared with the parent, hence have the same pfn and ptep as they used to, followed by a set of pages in the re-mmapped() region where the pfn's and ptep's are different, because that set of pages is no longer shared. What I find is that the re-mapped() region, the pfn's are different, but the ptep's have not changed. Hence, we've modified the parent address space rather than getting our own copy of that part of the address space. Now I'm not positive as to what the semantics SHOULD be here, so that may be the error involved, but it seems to me that if I mmap() the region private in the child, I should get a nice new private copy, and the pte's should no longer be shared with the parent. Is that the way you guys understand the semantics of this? Anyway take a look at my test case and see if it makes any sense to you. If it turns out my test case is in error, the mea culpa, and I'll fix the problems and try again. Best Regards, Ray > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- Ray Bryant AMD Performance Labs Austin, Tx 512-602-0038 (o) 512-507-7807 (c)