linux-kernel - Re: page_to_nid not linked in on PAE

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: <1268423424.2793.21.camel@sbs-t61.sc.intel.com>
Date:	Fri, 12 Mar 2010 11:50:24 -0800
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	Jan Engelhardt <jengelh@...ozas.de>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"hpa@...or.com" <hpa@...or.com>, Nick Piggin <npiggin@...e.de>,
	Andi Kleen <ak@...ux.intel.com>
Subject: Re: page_to_nid not linked in on PAE

On Wed, 2010-03-10 at 02:30 -0800, Jan Engelhardt wrote:
> On Tuesday 2010-03-09 13:32, Jan Engelhardt wrote:
> >
> >I have here a compile error with 2.6.33 related to some change in
> >page flags. The offending commit, according to bisect, is
> >
> >commit 46cf98cdaef5471926010b5bddf84c44ec177fdd
> >
> >    x86, pat: Generalize the use of page flag PG_uncached
> >    
> >$ make ARCH=i386 vmlinux
> > ...
> >  LD      .tmp_vmlinux1
> >arch/x86/built-in.o: In function `dma_generic_alloc_coherent':
> >(.text+0x42b2): undefined reference to `page_to_nid'
> ...
> 
> Due to the addition of page flags (like in the commit above),
> there are less bits to encode the node.
> In other words, reducing CONFIG_NODES_SHIFT works around the problem.
> But that can't really be a terminal solution.

Jan, Even with out using the PG_head, PG_tail, PG_uncached and
PG_hwpoison, by allowing the NODES_SHIFT to have a maximum value of 9 on
32bit kernel, can still result in the page flags to runout and result in
this problem. Best solution for now is to limit the NODES_SHIFT to 5. I
don't know of any platforms that have > 32nodes and where we care about
32bit linux kernel. So it should be ok as a fix. If someone in future
cares about > 32 nodes for 32bit kernel, then we can think of a better
solution. Do you agree? I copied Andi/Nick for their eyes aswell on
this.

Peter, Are you ok with this approach?

thanks,
suresh
---

From: Suresh Siddha <suresh.b.siddha@...el.com>
Subject: x86_32: limit the NODES_SHIFT to 5 to avoid page flags to run out

Jan Engelhardt reported this compilation failure with
32bit PAE kernel + !SPARSEMEM + NUMA
> arch/x86/built-in.o: In function `dma_generic_alloc_coherent':
> (.text+0x42b2): undefined reference to `page_to_nid'

This is as a result of running out the page flags to represent node id.

Currently NODES_SHIFT is limited to the max value of 9. With the value of 9
and even with !CONFIG_PAGEFLAGS_EXTENDED && !CONFIG_MEMORY_FAILURE &&
!CONFIG_ARCH_USES_PG_UNCACHED, we can easily run out the page flags
(as 9 bits for representing nid, 2 bits for representing section, leaving
21 bits for page flags. And even without the above mentioned config options
we have the need for 22 bits of page flags)

So limit the NODES_SHIFT to 5 to avoid page flags to run out on 32bit platforms.
Practically no one cares for the 32bit kernel on a platform with > 32nodes.

Reported-by: Jan Engelhardt <jengelh@...ozas.de>
Signed-off-by: Suresh Siddha <suresh.b.siddha@...el.com>
---

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index eb40925..6455a34 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1181,7 +1181,9 @@ config NUMA_EMU

 config NODES_SHIFT
 	int "Maximum NUMA Nodes (as a power of 2)" if !MAXSMP
-	range 1 9
+	range 1 9 if X86_64
+	range 1 5 if X86_32
+	# On 32-bit, too big of NODES_SHIFT can cause the page flags to run out.
 	default "9" if MAXSMP
 	default "6" if X86_64
 	default "4" if X86_NUMAQ

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