lkml.org 
[lkml]   [2013]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.)


\
 
 \ /
  Last update: 2013-01-28 00:41    [W:0.278 / U:1.796 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site