Re: [BUG] set_mempolicy(MPOL_INTERLEAV) cause kernel panic

[David Rientjes]

On Fri, 17 Jul 2009, KAMEZAWA Hiroyuki wrote:

> IMHO, the application itseld should be notifed to change its mempolicy by
> hot-plug script on the host. While an application uses interleave, a new node
> hot-added is just a noise. I think "How pages are interleaved" should not be
> changed implicitly. Then, checking at set_mempolicy() seems sane. If notified,
> application can do page migration and rebuild his mapping in ideal way.
> 

Agreed, it doesn't seem helpful to add a node to MPOL_INTERLEAVE for 
memory hotplug; the same is probably true of MPOL_BIND as well since the 
application will never want to unknowingly expand its set of allowed 
nodes.  There's no case where MPOL_PREFERRED would want to implicitly 
switch to the added node.

I'm not convinced that we have to support hot-add in existing mempolicies 
at all.

> BUT I don't linke init->mem_allowed contains N_POSSIBLE...it should be initialized
> to N_HIGH_MEMORY, IMHO.
> 

It doesn't matter for the page allocator since zonelists will never 
include zones from nodes that aren't online, so the underlying bug here 
does seem to be the behavior of ->mems_allowed and we're probably only 
triggering it by mempolicies.  cpuset_track_online_nodes() should be 
keeping top_cpuset's mems_allowed consistent with N_HIGH_MEMORY and all 
descendents must have a subset of top_cpuset's nodes, though.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/