Re: Race in new page migration code?

Lee Schermerhorn
2006-01-17T18:46:11Z

On Tue, 2006-01-17 at 09:29 -0800, Christoph Lameter wrote:
> On Mon, 16 Jan 2006, Hugh Dickins wrote:
>
> > Hmm, that battery of unusual tests at the start of migrate_page_add
> > is odd: the tests don't quite match the comment, and it isn't clear
> > what reasoning lies behind the comment anyway.
>
> Here is patch to clarify the test. I'd be glad if someone could make
> the tests more accurate. This ultimately comes down to a concept of
> ownership of page by a process / mm_struct that we have to approximate.
>
> ===
>
> Explain the complicated check in migrate_page_add by putting the logic
> into a separate function migration_check. This way any enhancements can
> be easily added.
>
> Signed-off-by: Christoph Lameter <clameter@sgi.com>
>
> Index: linux-2.6.15/mm/mempolicy.c
> ===================================================================
> --- linux-2.6.15.orig/mm/mempolicy.c 2006-01-14 10:56:28.000000000 -0800
> +++ linux-2.6.15/mm/mempolicy.c 2006-01-17 09:24:20.000000000 -0800
> @@ -551,6 +551,37 @@ out:
> return rc;
> }
>
> +static inline int migration_check(struct mm_struct *mm, struct page *page)
> +{
> + /*
> + * If the page has no mapping then we do not track reverse mappings.
> + * Thus the page is not mapped by other mms, so its safe to move.
> + */
> + if (page->mapping)
should this be "if (!page->mapping)" ???
> + return 1;
> +

<snip>
> - if ((flags & MPOL_MF_MOVE_ALL) || !page->mapping || PageAnon(page) ||
like here ......................................^^^^^^^^^^^^^^
> - mapping_writably_mapped(page->mapping) ||
> - single_mm_mapping(vma->vm_mm, page->mapping))
> + if ((flags & MPOL_MF_MOVE_ALL) || migration_check(vma->vm_mm, page))
> if (isolate_lru_page(page) == 1)
> list_add(&page->lru, pagelist);
> }

Lee