lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 6 Apr 2010 17:05:20 -0700 From: Andrew Morton <akpm@...ux-foundation.org> To: Mel Gorman <mel@....ul.ie> Cc: Andrea Arcangeli <aarcange@...hat.com>, Christoph Lameter <cl@...ux-foundation.org>, Adam Litke <agl@...ibm.com>, Avi Kivity <avi@...hat.com>, David Rientjes <rientjes@...gle.com>, Minchan Kim <minchan.kim@...il.com>, KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>, KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>, Rik van Riel <riel@...hat.com>, linux-kernel@...r.kernel.org, linux-mm@...ck.org Subject: Re: [PATCH 01/14] mm,migration: Take a reference to the anon_vma before migrating On Fri, 2 Apr 2010 17:02:35 +0100 Mel Gorman <mel@....ul.ie> wrote: > rmap_walk_anon() does not use page_lock_anon_vma() for looking up and > locking an anon_vma and it does not appear to have sufficient locking to > ensure the anon_vma does not disappear from under it. > > This patch copies an approach used by KSM to take a reference on the > anon_vma while pages are being migrated. This should prevent rmap_walk() > running into nasty surprises later because anon_vma has been freed. > The code didn't exactly bend over backwards making itself easy for others to understand... > > diff --git a/include/linux/rmap.h b/include/linux/rmap.h > index d25bd22..567d43f 100644 > --- a/include/linux/rmap.h > +++ b/include/linux/rmap.h > @@ -29,6 +29,9 @@ struct anon_vma { > #ifdef CONFIG_KSM > atomic_t ksm_refcount; > #endif > +#ifdef CONFIG_MIGRATION > + atomic_t migrate_refcount; > +#endif Some documentation here describing the need for this thing and its runtime semantics would be appropriate. > /* > * NOTE: the LSB of the head.next is set by > * mm_take_all_locks() _after_ taking the above lock. So the > @@ -81,6 +84,26 @@ static inline int ksm_refcount(struct anon_vma *anon_vma) > return 0; > } > #endif /* CONFIG_KSM */ > +#ifdef CONFIG_MIGRATION > +static inline void migrate_refcount_init(struct anon_vma *anon_vma) > +{ > + atomic_set(&anon_vma->migrate_refcount, 0); > +} > + > +static inline int migrate_refcount(struct anon_vma *anon_vma) > +{ > + return atomic_read(&anon_vma->migrate_refcount); > +} > +#else > +static inline void migrate_refcount_init(struct anon_vma *anon_vma) > +{ > +} > + > +static inline int migrate_refcount(struct anon_vma *anon_vma) > +{ > + return 0; > +} > +#endif /* CONFIG_MIGRATE */ > > static inline struct anon_vma *page_anon_vma(struct page *page) > { > diff --git a/mm/migrate.c b/mm/migrate.c > index 6903abf..06e6316 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -542,6 +542,7 @@ static int unmap_and_move(new_page_t get_new_page, unsigned long private, > int rcu_locked = 0; > int charge = 0; > struct mem_cgroup *mem = NULL; > + struct anon_vma *anon_vma = NULL; > > if (!newpage) > return -ENOMEM; > @@ -598,6 +599,8 @@ static int unmap_and_move(new_page_t get_new_page, unsigned long private, > if (PageAnon(page)) { > rcu_read_lock(); > rcu_locked = 1; > + anon_vma = page_anon_vma(page); > + atomic_inc(&anon_vma->migrate_refcount); So no helper function for this. I guess a grep for `migrate_refcount' will find it OK. Can this count ever have a value > 1? I guess so.. > } > > /* > @@ -637,6 +640,15 @@ skip_unmap: > if (rc) > remove_migration_ptes(page, page); > rcu_unlock: > + > + /* Drop an anon_vma reference if we took one */ > + if (anon_vma && atomic_dec_and_lock(&anon_vma->migrate_refcount, &anon_vma->lock)) { > + int empty = list_empty(&anon_vma->head); > + spin_unlock(&anon_vma->lock); > + if (empty) > + anon_vma_free(anon_vma); > + } > + So... Why shouldn't this be testing ksm_refcount() too? Can we consolidate ksm_refcount and migrate_refcount into, err, `refcount'? > if (rcu_locked) > rcu_read_unlock(); > uncharge: > diff --git a/mm/rmap.c b/mm/rmap.c > index fcd593c..578d0fe 100644 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists