linux-kernel - Re: [PATCH 01/11] mm,migration: Take a reference to the anon

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100317114537.GF12388@csn.ul.ie>
Date:	Wed, 17 Mar 2010 11:45:38 +0000
From:	Mel Gorman <mel@....ul.ie>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	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>,
	Rik van Riel <riel@...hat.com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH 01/11] mm,migration: Take a reference to the anon_vma
	before migrating

On Wed, Mar 17, 2010 at 10:44:06AM +0900, KOSAKI Motohiro wrote:
> >  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);
> > +	}
> > +
> 
> Why don't we check ksm_refcount here?

The counts later get merged and the ksm code should be doing its own
checking. Checking both counts here would obscure what is going on and
not help after patch 3 of the series.

> Also, why drop_anon_vma() doesn't need check migrate_refcount?
> 

Same reason. Counts get merged later.


> plus, if we add this logic, we can remove SLAB_DESTROY_BY_RCU from 
> anon_vma_cachep and rcu_read_lock() from unmap_and_move(), I think.
> It is for preventing anon_vma recycle logic. but no free directly mean
> no memory recycle.
> 

This is true, but I don't think such a change belongs in this patch
series. If this series gets merged, then it would be sensible to investigate
if refcounting anon_vma is a good idea or would it be a bouncing write-shared
cacheline mess.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
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/