public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Adrian Bunk <bunk@stusta.de>, Linus Torvalds <torvalds@osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [0/3] 2.6.19-rc2: known regressions
Date: Fri, 20 Oct 2006 11:19:00 -0700	[thread overview]
Message-ID: <20061020111900.30d3cb03.akpm@osdl.org> (raw)
In-Reply-To: <20061020180722.GA8894@flint.arm.linux.org.uk>

On Fri, 20 Oct 2006 19:07:22 +0100
Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> > > Subject    : undefined reference to highest_possible_node_id
> > > References : http://lkml.org/lkml/2006/9/4/233
> > >              http://lkml.org/lkml/2006/10/15/11
> > > Submitter  : Olaf Hering <olaf@aepfle.de>
> > > Caused-By  : Greg Banks <gnb@melbourne.sgi.com>
> > >              commit 0f532f3861d2c4e5aa7dcd33fb18e9975eb28457
> > > Status     : unknown
> > 
> > Looking at this commit and the mails, it was known on the 4th September
> > that this patch caused build errors while this change was in -mm, yet it
> > still found its way into mainline on 2nd October.
> > 
> > Is anyone going to look at fixing this problem, or should we be asking
> > for the commit to be reverted?
> 
> Since everyone seems intent at ignoring this issue, here's a patch to
> try to solve it.

I sent the below to Linus yesterday...



From: Andrew Morton <akpm@osdl.org>

Qooting Adrian:

- net/sunrpc/svc.c uses highest_possible_node_id()

- include/linux/nodemask.h says highest_possible_node_id() is
  out-of-line #if MAX_NUMNODES > 1

- the out-of-line highest_possible_node_id() is in lib/cpumask.c

- lib/Makefile: lib-$(CONFIG_SMP) += cpumask.o
  CONFIG_ARCH_DISCONTIGMEM_ENABLE=y, CONFIG_SMP=n, CONFIG_SUNRPC=y

-> highest_possible_node_id() is used in net/sunrpc/svc.c
   CONFIG_NODES_SHIFT defined and > 0

-> include/linux/numa.h: MAX_NUMNODES > 1

-> compile error

The bug is not present on architectures where ARCH_DISCONTIGMEM_ENABLE 
depends on NUMA (but m32r isn't the only affected architecture).


So move the function into page_alloc.c

Cc: Adrian Bunk <bunk@stusta.de>
Cc: Paul Jackson <pj@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 lib/cpumask.c   |   16 ----------------
 mm/page_alloc.c |   16 ++++++++++++++++
 2 files changed, 16 insertions(+), 16 deletions(-)

diff -puN lib/cpumask.c~highest_possible_node_id-linkage-fix lib/cpumask.c
--- a/lib/cpumask.c~highest_possible_node_id-linkage-fix
+++ a/lib/cpumask.c
@@ -43,19 +43,3 @@ int __any_online_cpu(const cpumask_t *ma
 	return cpu;
 }
 EXPORT_SYMBOL(__any_online_cpu);
-
-#if MAX_NUMNODES > 1
-/*
- * Find the highest possible node id.
- */
-int highest_possible_node_id(void)
-{
-	unsigned int node;
-	unsigned int highest = 0;
-
-	for_each_node_mask(node, node_possible_map)
-		highest = node;
-	return highest;
-}
-EXPORT_SYMBOL(highest_possible_node_id);
-#endif
diff -puN mm/page_alloc.c~highest_possible_node_id-linkage-fix mm/page_alloc.c
--- a/mm/page_alloc.c~highest_possible_node_id-linkage-fix
+++ a/mm/page_alloc.c
@@ -3120,3 +3120,19 @@ unsigned long page_to_pfn(struct page *p
 EXPORT_SYMBOL(pfn_to_page);
 EXPORT_SYMBOL(page_to_pfn);
 #endif /* CONFIG_OUT_OF_LINE_PFN_TO_PAGE */
+
+#if MAX_NUMNODES > 1
+/*
+ * Find the highest possible node id.
+ */
+int highest_possible_node_id(void)
+{
+	unsigned int node;
+	unsigned int highest = 0;
+
+	for_each_node_mask(node, node_possible_map)
+		highest = node;
+	return highest;
+}
+EXPORT_SYMBOL(highest_possible_node_id);
+#endif
_


  reply	other threads:[~2006-10-20 18:22 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-13 16:49 Linux 2.6.19-rc2 Linus Torvalds
2006-10-13 17:40 ` Alistair John Strachan
2006-10-13 17:55   ` H. Peter Anvin
2006-10-13 20:52     ` Willy Tarreau
2006-10-13 17:57   ` Paolo Ornati
2006-10-13 17:59   ` Linus Torvalds
2006-10-13 17:42 ` Michal Piotrowski
2006-10-13 18:26   ` Michal Piotrowski
2006-10-13 18:34 ` Alex Romosan
2006-10-13 18:37 ` Olaf Hering
2006-10-14 11:14 ` [0/3] 2.6.19-rc2: known regressions Adrian Bunk
2006-10-14 11:22   ` [1/3] 2.6.19-rc2: known unfixed regressions Adrian Bunk
2006-10-14 11:54     ` Eric W. Biederman
2006-10-14 11:25   ` [2/3] 2.6.19-rc2: knwon regressions with workarounds Adrian Bunk
     [not found]   ` <20061014113409.GL30596@stusta.de>
2006-10-15 12:09     ` [3/3] 2.6.19-r2: known regressions with patches Jean Delvare
2006-10-15 12:24   ` [0/3] 2.6.19-rc2: known regressions Russell King
2006-10-15 12:42     ` Adrian Bunk
2006-10-19  8:17       ` Russell King
2006-10-20 18:07         ` Russell King
2006-10-20 18:19           ` Andrew Morton [this message]
2006-10-20 18:31             ` Russell King
2006-10-20 18:50               ` Linus Torvalds
2006-10-20 18:59                 ` Russell King
2006-10-20 21:06                   ` Linus Torvalds
2006-10-20 18:31           ` Linus Torvalds
2006-10-29 10:33   ` Guennadi Liakhovetski
2006-10-29 20:17     ` Linus Torvalds
2006-10-29 22:34       ` r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions) Francois Romieu
2006-10-30  0:20         ` Guennadi Liakhovetski
2006-10-30 12:01           ` Francois Romieu
2006-10-30 20:59             ` Guennadi Liakhovetski
2006-10-30 21:17               ` Guennadi Liakhovetski
2006-10-30 23:44                 ` Francois Romieu
2006-10-31 19:02                   ` Guennadi Liakhovetski
2006-10-31 23:05                     ` Francois Romieu
2006-10-31 23:37                       ` Guennadi Liakhovetski
2006-11-01  5:00                       ` Lennert Buytenhek
2006-11-01 19:01                       ` Darren Salt
2006-11-01 21:35                         ` Francois Romieu
2006-11-03 14:52                         ` Azam, Syed S
2006-10-30 23:25               ` Francois Romieu
2006-10-30 13:02         ` Oleg Verych
     [not found] ` <20061017155934.GC3502@stusta.de>
2006-10-17 16:23   ` 2.6.19-rc2: known unfixed regressions (v2) Olaf Hering
2006-10-17 16:29     ` Adrian Bunk
     [not found]   ` <4534C7A7.7000607@hp.com>
     [not found]     ` <20061018221520.GK3502@stusta.de>
     [not found]       ` <20061018231844.GA16857@devserv.devel.redhat.com>
2006-10-19 15:26         ` [2.6.19 patch] drivers/ide/pci/generic.c: re-add the __setup("all-generic-ide",...) Adrian Bunk
2006-10-19 16:07           ` Randy Dunlap
2006-10-19 16:13             ` Adrian Bunk
2006-10-19 16:29               ` Alan Cox
2006-10-20 21:05                 ` Adrian Bunk
2006-10-21 17:54                   ` Randy Dunlap
2006-10-20 18:30 ` Linux 2.6.19-rc2 Kevin Radloff
2006-10-20 20:53   ` Alan Cox
2006-10-20 21:12     ` Jeff Garzik
2006-10-22 12:23 ` 2.6.19-rc2: known unfixed regressions (v3) Adrian Bunk
2006-10-22 13:23   ` Andi Kleen
2006-10-22 14:46   ` Gene Heskett
2006-10-22 15:17     ` Alex Romosan
2006-10-23  0:55       ` Gene Heskett
2006-10-23 11:32   ` Andrey Panin
2006-10-23 15:20   ` Meelis Roos
2006-10-23 20:59     ` Adrian Bunk
2006-10-24 14:57       ` Stefan Richter
2006-10-24 19:48         ` Adrian Bunk
2006-10-24 15:00   ` Michael S. Tsirkin
2006-10-25  8:28     ` Pavel Machek
2006-10-25  8:37       ` Michael S. Tsirkin
2006-10-24 17:27   ` Prakash Punnoor
2006-10-24 19:58     ` Adrian Bunk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061020111900.30d3cb03.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=bunk@stusta.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox