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

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: <20090728102411.2a18c2e3.kamezawa.hiroyu@jp.fujitsu.com>
Date:	Tue, 28 Jul 2009 10:24:11 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc:	David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Lee Schermerhorn <lee.schermerhorn@...com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	miaox@...fujitsu.com, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Paul Menage <menage@...gle.com>,
	Nick Piggin <nickpiggin@...oo.com.au>, y-goto@...fujitsu.com,
	Pekka Enberg <penberg@...helsinki.fi>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [BUG] set_mempolicy(MPOL_INTERLEAV) cause kernel panic

On Tue, 28 Jul 2009 10:11:57 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> wrote:

> On Mon, 27 Jul 2009 18:02:50 -0700 (PDT)
> David Rientjes <rientjes@...gle.com> wrote:
> 
> > On Tue, 28 Jul 2009, KAMEZAWA Hiroyuki wrote:
> > 
> > > > The problem originally reported here doesn't appear to have anything to do 
> > > > with hotplug, it looks like it is the result of Lee's observation that 
> > > > ia64 defaults top_cpuset's mems to N_POSSIBLE, which _should_ have been 
> > > > updated by cpuset_init_smp(). 
> > > cpuset_init_smp() just updates cpuset's mask.
> > > init's task->mems_allowed is intizialized independently from cpuset's mask.
> > > 
> > 
> > Presumably the bug is that N_HIGH_MEMORY is not a subset of N_ONLINE at 
> > this point on ia64.
> > 
> N_HIGH_MEMORY is must be subset of N_ONLINE, at the any moment. Hmm,
> I'll look into what happens in ia64 world.
> 

At quick look, N_HIGH_MEMORY is set here while init. (I ignore hoplug now.)

== before init==
  60 #ifndef CONFIG_NUMA
  61         [N_NORMAL_MEMORY] = { { [0] = 1UL } },
  62 #ifdef CONFIG_HIGHMEM
  63         [N_HIGH_MEMORY] = { { [0] = 1UL } },
  64 #endif
== 
3860 static unsigned long __init early_calculate_totalpages(void)
3861 {
  ....
3869                 if (pages)
3870                         node_set_state(early_node_map[i].nid, N_HIGH_MEMORY);
3871         }
==
4041 void __init free_area_init_nodes(unsigned long *max_zone_pfn)
4042 {
4105                 if (pgdat->node_present_pages)
4106                         node_set_state(nid, N_HIGH_MEMORY);
==


All of them are done while mem_init(). Then if N_HIGH_MEMORY is not correct at
kernel_init(). It's bug.

I think what Lee and Miao pointed out is just a hotplug problem.
Ok, I'll try some patch but it'll take some hours.

Thanks,
-Kame

--
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/