linux-kernel - Re: [PATCH 11/11] ksm: stop hotremove lockdep warning

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]

Date:	Sun, 27 Jan 2013 15:35:21 -0800 (PST)
From:	Hugh Dickins <hughd@...gle.com>
To:	Simon Jeons <simon.jeons@...il.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Petr Holasek <pholasek@...hat.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Izik Eidus <izik.eidus@...ellosystems.com>,
	Gerald Schaefer <gerald.schaefer@...ibm.com>,
	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 11/11] ksm: stop hotremove lockdep warning

On Sun, 27 Jan 2013, Simon Jeons wrote:
> On Fri, 2013-01-25 at 18:10 -0800, Hugh Dickins wrote:
> > @@ -2098,15 +2117,15 @@ static int ksm_memory_callback(struct no
> >  	switch (action) {
> >  	case MEM_GOING_OFFLINE:
> >  		/*
> > -		 * Keep it very simple for now: just lock out ksmd and
> > -		 * MADV_UNMERGEABLE while any memory is going offline.
> > -		 * mutex_lock_nested() is necessary because lockdep was alarmed
> > -		 * that here we take ksm_thread_mutex inside notifier chain
> > -		 * mutex, and later take notifier chain mutex inside
> > -		 * ksm_thread_mutex to unlock it.   But that's safe because both
> > -		 * are inside mem_hotplug_mutex.
> > +		 * Prevent ksm_do_scan(), unmerge_and_remove_all_rmap_items()
> > +		 * and remove_all_stable_nodes() while memory is going offline:
> > +		 * it is unsafe for them to touch the stable tree at this time.
> > +		 * But unmerge_ksm_pages(), rmap lookups and other entry points
> 
> Why unmerge_ksm_pages beneath us is safe for ksm memory hotremove?
> 
> > +		 * which do not need the ksm_thread_mutex are all safe.

It's just like userspace doing a write-fault on every KSM page in the vma.
If that were unsafe for memory hotremove, then it would not be KSM's
problem, memory hotremove would already be unsafe.  (But memory hotremove
is safe because it migrates away from all the pages to be removed before
it can reach MEM_OFFLINE.)
--
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/