linux-next: rr tree build failure

linux-next: rr tree build failure

[Stephen Rothwell]

Hi Rusty,

Today's linux-next build (sparc defconfig) failed like this:

arch/sparc/mm/extable.c: In function 'trim_init_extable':
arch/sparc/mm/extable.c:78: error: too few arguments to function 'within_module_init'

Caused by commit 2ac595c3960b80139e895c4e13e851ed6dfd127a ("module: trim
exception table on init free").

I applied the following patch (because I did not want to have to rebuild
everything again).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 11 Jun 2009 18:53:13 +1000
Subject: [PATCH] rr: fix up for sparc32 extable

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/sparc/mm/extable.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/sparc/mm/extable.c b/arch/sparc/mm/extable.c
index 6b5c373..a61c349 100644
--- a/arch/sparc/mm/extable.c
+++ b/arch/sparc/mm/extable.c
@@ -75,7 +75,7 @@ void trim_init_extable(struct module *m)
 	for (i = 0; i < m->num_exentries; i += range ? 2 : 1) {
 		range = m->extable[i].fixup == 0;
 
-		if (within_module_init(m->extable[i].insn)) {
+		if (within_module_init(m->extable[i].insn, m)) {
 			m->extable[i].fixup = -1;
 			if (range)
 				m->extable[i+1].fixup = -1;
-- 
1.6.3.1

Re: linux-next: rr tree build failure

[Rusty Russell]

On Thu, 11 Jun 2009 06:37:28 pm Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next build (sparc defconfig) failed like this:
>
> arch/sparc/mm/extable.c: In function 'trim_init_extable':
> arch/sparc/mm/extable.c:78: error: too few arguments to function
> 'within_module_init'

Thanks, I've applied your fix.

Thanks,
Rusty.

linux-next: rr tree build failure

[Stephen Rothwell]

Hi Rusty,

Today's linux-next build (x86_64 allmodconfig) failed like this:

arch/x86/kernel/cpu/cpufreq/powernow-k8.c: In function 'powernowk8_target':
arch/x86/kernel/cpu/cpufreq/powernow-k8.c:1139: error: implicit declaration of function 'tsk_cpumask'
arch/x86/kernel/cpu/cpufreq/powernow-k8.c:1139: warning: passing argument 2 of 'cpumask_copy' makes pointer from integer without a cast
include/linux/cpumask.h:466: note: expected 'const struct cpumask *' but argument is of type 'int'

Caused by commit 9dd4c5ab546fcac98cfb9ca24ed5cc1bf7f08334
("cpumask:tsk_cpus_allowed-not-tsk_cpumask") from the rr tree interacting
with commit b8cbe7e82ec8b55d7bbdde66fc69e788fde00dc6 ("[CPUFREQ] cpumask:
don't put a cpumask on the stack in x86...cpufreq/powernow-k8.c") from
the cpufreq tree.

I have applied this merge fix up patch and can carry it as necessary:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 11 Dec 2009 12:21:00 +1100
Subject: [PATCH] rr: cpufreq: fix up for api name change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/kernel/cpu/cpufreq/powernow-k8.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/cpu/cpufreq/powernow-k8.c b/arch/x86/kernel/cpu/cpufreq/powernow-k8.c
index a9df944..f125e5c 100644
--- a/arch/x86/kernel/cpu/cpufreq/powernow-k8.c
+++ b/arch/x86/kernel/cpu/cpufreq/powernow-k8.c
@@ -1136,7 +1136,7 @@ static int powernowk8_target(struct cpufreq_policy *pol,
 	if (!alloc_cpumask_var(&oldmask, GFP_KERNEL))
 		return -ENOMEM;
 
-	cpumask_copy(oldmask, tsk_cpumask(current));
+	cpumask_copy(oldmask, tsk_cpus_allowed(current));
 	set_cpus_allowed_ptr(current, cpumask_of(pol->cpu));
 
 	if (smp_processor_id() != pol->cpu) {
-- 
1.6.5.4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: linux-next: rr tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2176 bytes --]

Hi Rusty,

On Fri, 11 Dec 2009 12:26:48 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> arch/x86/kernel/cpu/cpufreq/powernow-k8.c: In function 'powernowk8_target':
> arch/x86/kernel/cpu/cpufreq/powernow-k8.c:1139: error: implicit declaration of function 'tsk_cpumask'
> arch/x86/kernel/cpu/cpufreq/powernow-k8.c:1139: warning: passing argument 2 of 'cpumask_copy' makes pointer from integer without a cast
> include/linux/cpumask.h:466: note: expected 'const struct cpumask *' but argument is of type 'int'
> 
> Caused by commit 9dd4c5ab546fcac98cfb9ca24ed5cc1bf7f08334
> ("cpumask:tsk_cpus_allowed-not-tsk_cpumask") from the rr tree interacting
> with commit b8cbe7e82ec8b55d7bbdde66fc69e788fde00dc6 ("[CPUFREQ] cpumask:
> don't put a cpumask on the stack in x86...cpufreq/powernow-k8.c") from
> the cpufreq tree.

The cpufreq patch above is now in Linus' tree, so You should add the
patch below to your tree (or squash it into the affected patch).

> I have applied this merge fix up patch and can carry it as necessary:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 11 Dec 2009 12:21:00 +1100
> Subject: [PATCH] rr: cpufreq: fix up for api name change
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/x86/kernel/cpu/cpufreq/powernow-k8.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/cpufreq/powernow-k8.c b/arch/x86/kernel/cpu/cpufreq/powernow-k8.c
> index a9df944..f125e5c 100644
> --- a/arch/x86/kernel/cpu/cpufreq/powernow-k8.c
> +++ b/arch/x86/kernel/cpu/cpufreq/powernow-k8.c
> @@ -1136,7 +1136,7 @@ static int powernowk8_target(struct cpufreq_policy *pol,
>  	if (!alloc_cpumask_var(&oldmask, GFP_KERNEL))
>  		return -ENOMEM;
>  
> -	cpumask_copy(oldmask, tsk_cpumask(current));
> +	cpumask_copy(oldmask, tsk_cpus_allowed(current));
>  	set_cpus_allowed_ptr(current, cpumask_of(pol->cpu));
>  
>  	if (smp_processor_id() != pol->cpu) {

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: rr tree build failure

[Rusty Russell]

On Mon, 14 Dec 2009 03:05:28 pm Stephen Rothwell wrote:
> Hi Rusty,
> 
> On Fri, 11 Dec 2009 12:26:48 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > 
> > arch/x86/kernel/cpu/cpufreq/powernow-k8.c: In function 'powernowk8_target':
> > arch/x86/kernel/cpu/cpufreq/powernow-k8.c:1139: error: implicit declaration of function 'tsk_cpumask'
> > arch/x86/kernel/cpu/cpufreq/powernow-k8.c:1139: warning: passing argument 2 of 'cpumask_copy' makes pointer from integer without a cast
> > include/linux/cpumask.h:466: note: expected 'const struct cpumask *' but argument is of type 'int'
> > 
> > Caused by commit 9dd4c5ab546fcac98cfb9ca24ed5cc1bf7f08334
> > ("cpumask:tsk_cpus_allowed-not-tsk_cpumask") from the rr tree interacting
> > with commit b8cbe7e82ec8b55d7bbdde66fc69e788fde00dc6 ("[CPUFREQ] cpumask:
> > don't put a cpumask on the stack in x86...cpufreq/powernow-k8.c") from
> > the cpufreq tree.
> 
> The cpufreq patch above is now in Linus' tree, so You should add the
> patch below to your tree (or squash it into the affected patch).

Thanks, done and rebased.

Cheers,
Rusty.

Re: linux-next: rr tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

Hi Rusty,

On Tue, 15 Dec 2009 14:22:29 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote:
>
> On Mon, 14 Dec 2009 03:05:28 pm Stephen Rothwell wrote:
> > 
> > The cpufreq patch above is now in Linus' tree, so You should add the
> > patch below to your tree (or squash it into the affected patch).
> 
> Thanks, done and rebased.

Great, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: rr tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

Hi Rusty,

On Tue, 15 Dec 2009 14:22:29 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote:
>
> On Mon, 14 Dec 2009 03:05:28 pm Stephen Rothwell wrote:
> > 
> > On Fri, 11 Dec 2009 12:26:48 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > > 
> > > arch/x86/kernel/cpu/cpufreq/powernow-k8.c: In function 'powernowk8_target':
> > > arch/x86/kernel/cpu/cpufreq/powernow-k8.c:1139: error: implicit declaration of function 'tsk_cpumask'
> > > arch/x86/kernel/cpu/cpufreq/powernow-k8.c:1139: warning: passing argument 2 of 'cpumask_copy' makes pointer from integer without a cast
> > > include/linux/cpumask.h:466: note: expected 'const struct cpumask *' but argument is of type 'int'
> > > 
> > > Caused by commit 9dd4c5ab546fcac98cfb9ca24ed5cc1bf7f08334
> > > ("cpumask:tsk_cpus_allowed-not-tsk_cpumask") from the rr tree interacting
> > > with commit b8cbe7e82ec8b55d7bbdde66fc69e788fde00dc6 ("[CPUFREQ] cpumask:
> > > don't put a cpumask on the stack in x86...cpufreq/powernow-k8.c") from
> > > the cpufreq tree.
> > 
> > The cpufreq patch above is now in Linus' tree, so You should add the
> > patch below to your tree (or squash it into the affected patch).
> 
> Thanks, done and rebased.

But not exported/uploaded ... :-(
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

linux-next: rr tree build failure

[Stephen Rothwell]

Hi Rusty,

Today's linux-next build (powerpc ppc44x_defconfig) failed like this:

.tmp_exports-asm.o: In function `__ksymtab_pci_alloc_consistent':
(__ksymtab_sorted+0x2a30): undefined reference to `pci_alloc_consistent'
.tmp_exports-asm.o: In function `__ksymtab_pci_free_consistent':
(__ksymtab_sorted+0x2b70): undefined reference to `pci_free_consistent'

Caused by the powerpc architecture EXPORTing static inlines (for 32 bit
builds) interacting with changes in the rr tree.

I have applied this patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 12 Nov 2009 18:54:13 +1100
Subject: [PATCH] powerpc: do not export pci_alloc/free_consistent

Since they are static inline functions.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/kernel/ppc_ksyms.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index 07115d6..4254514 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -96,8 +96,6 @@ EXPORT_SYMBOL(copy_4K_page);
 EXPORT_SYMBOL(isa_io_base);
 EXPORT_SYMBOL(isa_mem_base);
 EXPORT_SYMBOL(pci_dram_offset);
-EXPORT_SYMBOL(pci_alloc_consistent);
-EXPORT_SYMBOL(pci_free_consistent);
 #endif /* CONFIG_PCI */
 
 EXPORT_SYMBOL(start_thread);
-- 
1.6.5.2

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: linux-next: rr tree build failure

[Benjamin Herrenschmidt]

On Thu, 2009-11-12 at 19:03 +1100, Stephen Rothwell wrote:
> Hi Rusty,
> 
> Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
> 
> .tmp_exports-asm.o: In function `__ksymtab_pci_alloc_consistent':
> (__ksymtab_sorted+0x2a30): undefined reference to `pci_alloc_consistent'
> .tmp_exports-asm.o: In function `__ksymtab_pci_free_consistent':
> (__ksymtab_sorted+0x2b70): undefined reference to `pci_free_consistent'
> 
> Caused by the powerpc architecture EXPORTing static inlines (for 32 bit
> builds) interacting with changes in the rr tree.
> 
> I have applied this patch for today:

Thanks. Our EXPORTs are bogus (probably leftovers) it seems. I'll dbl
check tomorrow but that looks like a patch I should pickup in powerpc
-next anyways.

Cheers,
Ben.

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 12 Nov 2009 18:54:13 +1100
> Subject: [PATCH] powerpc: do not export pci_alloc/free_consistent
> 
> Since they are static inline functions.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/powerpc/kernel/ppc_ksyms.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
> index 07115d6..4254514 100644
> --- a/arch/powerpc/kernel/ppc_ksyms.c
> +++ b/arch/powerpc/kernel/ppc_ksyms.c
> @@ -96,8 +96,6 @@ EXPORT_SYMBOL(copy_4K_page);
>  EXPORT_SYMBOL(isa_io_base);
>  EXPORT_SYMBOL(isa_mem_base);
>  EXPORT_SYMBOL(pci_dram_offset);
> -EXPORT_SYMBOL(pci_alloc_consistent);
> -EXPORT_SYMBOL(pci_free_consistent);
>  #endif /* CONFIG_PCI */
>  
>  EXPORT_SYMBOL(start_thread);
> -- 
> 1.6.5.2
> 

Re: linux-next: rr tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

Hi Ben,

On Thu, 12 Nov 2009 20:02:00 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> Thanks. Our EXPORTs are bogus (probably leftovers) it seems. I'll dbl
> check tomorrow but that looks like a patch I should pickup in powerpc
> -next anyways.

That was the idea, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

linux-next: rr tree build failure

[Stephen Rothwell]

Hi Rusty,

Today's linux-next build (powerpc allnoconfig) failed like this:

scripts/mod/modpost.c:18:42: error: ../../include/linux/autoconf.h: No such file or directory

Caused by commit acd9e0c7d0b4a1cc02c27088a2b2322acc6d0793 ("module: make
MODULE_SYMBOL_PREFIX into a CONFIG option") interacting with commit
cf1320106e706875e6e14db8d5299f1d552f565e ("kbuild: move autoconf.h to
include/generated") from the kbuild tree.

I have applied the following patch for today (and will continue to use
it):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 12 Nov 2009 18:33:17 +1100
Subject: [PATCH] modpost: autoconf.h has moved to include/generated

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 scripts/mod/modpost.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index f6be2e9..769ea95 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -15,7 +15,7 @@
 #include <stdio.h>
 #include <ctype.h>
 #include "modpost.h"
-#include "../../include/linux/autoconf.h"
+#include "../../include/generated/autoconf.h"
 #include "../../include/linux/license.h"
 
 /* Some toolchains use a `_' prefix for all user symbols. */
-- 
1.6.5.2

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

linux-next: rr tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

Hi Rusty,

Today's linux-next build (x86_64 allmodconfig) failed like this:

.tmp_exports-asm.o: In function `__ksymtab_load_gs_index':
(__ksymtab_sorted+0x5b40): undefined reference to `load_gs_index'

I have used the version of the rr tree from next-20091110 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: rr tree build failure

[Rusty Russell]

On Wed, 11 Nov 2009 01:31:26 pm Stephen Rothwell wrote:
> Hi Rusty,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> .tmp_exports-asm.o: In function `__ksymtab_load_gs_index':
> (__ksymtab_sorted+0x5b40): undefined reference to `load_gs_index'
> 
> I have used the version of the rr tree from next-20091110 for today.

It's inline and exported when CONFIG_PARAVIRT=y.  Which is wrong.

Here's the patch I've put in my series for tomorrow's linux-next:

Subject: x86: don't export inline function

For CONFIG_PARAVIRT, load_gs_index is an inline function (it's #defined
to native_load_gs_index otherwise).

Exporting an inline function breaks the new assembler-based alphabetical
sorted symbol list:

Today's linux-next build (x86_64 allmodconfig) failed like this:

	.tmp_exports-asm.o: In function `__ksymtab_load_gs_index':
	(__ksymtab_sorted+0x5b40): undefined reference to `load_gs_index'

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
To: x86@kernel.org
Cc: alan-jenkins@tuffmail.co.uk

diff --git a/arch/x86/kernel/x8664_ksyms_64.c b/arch/x86/kernel/x8664_ksyms_64.c
--- a/arch/x86/kernel/x8664_ksyms_64.c
+++ b/arch/x86/kernel/x8664_ksyms_64.c
@@ -57,4 +57,6 @@ EXPORT_SYMBOL(__memcpy);
 
 EXPORT_SYMBOL(empty_zero_page);
 EXPORT_SYMBOL(init_level4_pgt);
-EXPORT_SYMBOL(load_gs_index);
+#ifndef CONFIG_PARAVIRT
+EXPORT_SYMBOL(native_load_gs_index);
+#endif

linux-next: rr tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

Hi Rusty,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

kernel/module.c: In function 'set_section_ro_nx':
kernel/module.c:1549: error: implicit declaration of function 'set_memory_ro'
kernel/module.c:1560: error: implicit declaration of function 'set_memory_nx'
kernel/module.c: In function 'unset_section_ro_nx':
kernel/module.c:1575: error: implicit declaration of function 'set_memory_rw'

Caused by commit 25306e21864c2a220d6fa2e0632425028aa9626c
("module:ro-nx-protection") which uses these interfaces that are only
defined on x86 ...

I have used the version of the rr tree from next-20090908 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: rr tree build failure

[Siarhei Liakh]

On Tue, Sep 8, 2009 at 11:47 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Rusty,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> kernel/module.c: In function 'set_section_ro_nx':
> kernel/module.c:1549: error: implicit declaration of function 'set_memory_ro'
> kernel/module.c:1560: error: implicit declaration of function 'set_memory_nx'
> kernel/module.c: In function 'unset_section_ro_nx':
> kernel/module.c:1575: error: implicit declaration of function 'set_memory_rw'
>
> Caused by commit 25306e21864c2a220d6fa2e0632425028aa9626c
> ("module:ro-nx-protection") which uses these interfaces that are only
> defined on x86 ...

Looks like I have made some bad assumptions. I will re-write the
original patch to be x86-only.

Sorry for breaking the build.

Re: linux-next: rr tree build failure

[Siarhei Liakh]

On Tue, Sep 8, 2009 at 11:47 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Rusty,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> kernel/module.c: In function 'set_section_ro_nx':
> kernel/module.c:1549: error: implicit declaration of function 'set_memory_ro'
> kernel/module.c:1560: error: implicit declaration of function 'set_memory_nx'
> kernel/module.c: In function 'unset_section_ro_nx':
> kernel/module.c:1575: error: implicit declaration of function 'set_memory_rw'
>
> Caused by commit 25306e21864c2a220d6fa2e0632425028aa9626c
> ("module:ro-nx-protection") which uses these interfaces that are only
> defined on x86 ...
>
> I have used the version of the rr tree from next-20090908 for today.

I have posted a replacement patch for that commit: "[PATCH v6] RO/NX
protection for loadable kernel modules"
Please let me know if you would rather see a short "patch patch"
rather than complete patch replacement. The fix, essentially, is to
encapsulate entire bodies of unset_section_ro_nx() and
set_section_ro_nx() inside #ifdef CONFIG_X86 ... #endif. This way
set_memory_* will be called only on x86.

Thanks.

Re: linux-next: rr tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

Hi Rusty,

On Wed, 9 Sep 2009 13:47:52 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> kernel/module.c: In function 'set_section_ro_nx':
> kernel/module.c:1549: error: implicit declaration of function 'set_memory_ro'
> kernel/module.c:1560: error: implicit declaration of function 'set_memory_nx'
> kernel/module.c: In function 'unset_section_ro_nx':
> kernel/module.c:1575: error: implicit declaration of function 'set_memory_rw'
> 
> Caused by commit 25306e21864c2a220d6fa2e0632425028aa9626c
> ("module:ro-nx-protection") which uses these interfaces that are only
> defined on x86 ...
> 
> I have used the version of the rr tree from next-20090908 for today.

Still happening ... Siarhei posted a replacement patch on Sept 11.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: rr tree build failure

[Rusty Russell]

On Tue, 15 Sep 2009 12:57:48 pm Stephen Rothwell wrote:
> Hi Rusty,
> 
> On Wed, 9 Sep 2009 13:47:52 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:.
> 
> Still happening ... Siarhei posted a replacement patch on Sept 11.

Sorry, was on leave for 3 weeks.  I hope Linus will be flexible; many of these
patches have been in linux-next for months now, it'd be nice to unload.

Thanks,
Rusty.

linux-next: rr tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

Hi Rusty,

Today's linux-next build (x86_64 allmodconfig) failed like this:

drivers/acpi/osl.c: In function 'bind_to_cpu0':
drivers/acpi/osl.c:194: error: implicit declaration of function 'set_cpus_allowed'

Caused by commit 74b5820808215f65b70b05a099d6d3c969b82689 ("ACPI: bind
workqueues to CPU 0 to avoid SMI corruption") (from the acpi tree but now
in Linus' tree) interacting with commit
17e249fb40c814a72f08c1356cb47ec9f87f81a8
("cpumask:remove-set_cpus_allowed") from the rr tree.

I have reverted that rr tree commit for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: rr tree build failure

[Bjorn Helgaas]

On Sunday 02 August 2009 09:32:03 pm Stephen Rothwell wrote:
> Hi Rusty,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> drivers/acpi/osl.c: In function 'bind_to_cpu0':
> drivers/acpi/osl.c:194: error: implicit declaration of function 'set_cpus_allowed'
> 
> Caused by commit 74b5820808215f65b70b05a099d6d3c969b82689 ("ACPI: bind
> workqueues to CPU 0 to avoid SMI corruption") (from the acpi tree but now
> in Linus' tree) interacting with commit
> 17e249fb40c814a72f08c1356cb47ec9f87f81a8
> ("cpumask:remove-set_cpus_allowed") from the rr tree.
> 
> I have reverted that rr tree commit for today.

Looks like I'm doing this the wrong way (by passing a cpumask on the
stack).  I'll try to figure out the approved way of doing this and
send a followup patch.

Bjorn

Re: linux-next: rr tree build failure

[Bjorn Helgaas]

On Sunday 02 August 2009 09:32:03 pm Stephen Rothwell wrote:
> Hi Rusty,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> drivers/acpi/osl.c: In function 'bind_to_cpu0':
> drivers/acpi/osl.c:194: error: implicit declaration of function 'set_cpus_allowed'
> 
> Caused by commit 74b5820808215f65b70b05a099d6d3c969b82689 ("ACPI: bind
> workqueues to CPU 0 to avoid SMI corruption") (from the acpi tree but now
> in Linus' tree) interacting with commit
> 17e249fb40c814a72f08c1356cb47ec9f87f81a8
> ("cpumask:remove-set_cpus_allowed") from the rr tree.
> 
> I have reverted that rr tree commit for today.

Here's a patch to fix this.  Since Linus' tree still contains instances
of set_cpus_allowed(), I'm guessing this patch should be added to the rr
tree?

Bjorn



ACPI: remove cpumask_t usage

set_cpus_allowed() is on the way out; replace it with
set_cpus_allowed_ptr().

Reference: http://lkml.org/lkml/2008/11/6/448

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Rusty Russell <rusty@rustcorp.com.au>

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 5691f16..e196a75 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -191,7 +191,7 @@ acpi_status __init acpi_os_initialize(void)
 
 static void bind_to_cpu0(struct work_struct *work)
 {
-	set_cpus_allowed(current, cpumask_of_cpu(0));
+	set_cpus_allowed_ptr(current, cpumask_of(0));
 	kfree(work);
 }
 

Re: linux-next: rr tree build failure

[Rusty Russell]

On Tue, 4 Aug 2009 05:52:27 am Bjorn Helgaas wrote:
> On Sunday 02 August 2009 09:32:03 pm Stephen Rothwell wrote:
> > Hi Rusty,
> > 
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > 
> > drivers/acpi/osl.c: In function 'bind_to_cpu0':
> > drivers/acpi/osl.c:194: error: implicit declaration of function 'set_cpus_allowed'
> > 
> > Caused by commit 74b5820808215f65b70b05a099d6d3c969b82689 ("ACPI: bind
> > workqueues to CPU 0 to avoid SMI corruption") (from the acpi tree but now
> > in Linus' tree) interacting with commit
> > 17e249fb40c814a72f08c1356cb47ec9f87f81a8
> > ("cpumask:remove-set_cpus_allowed") from the rr tree.
> > 
> > I have reverted that rr tree commit for today.
> 
> Here's a patch to fix this.  Since Linus' tree still contains instances
> of set_cpus_allowed(), I'm guessing this patch should be added to the rr
> tree?
> 
> Bjorn

Yep, my series removes it, at least for CONFIG_CPUMASK_OFFSTACK=y.

Thanks!
Rusty.

Re: linux-next: rr tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

Hi Guys,

On Tue, 4 Aug 2009 08:48:26 +0930 Rusty Russell <rusty@rustcorp.com.au> wrote:
>
> On Tue, 4 Aug 2009 05:52:27 am Bjorn Helgaas wrote:
> > On Sunday 02 August 2009 09:32:03 pm Stephen Rothwell wrote:
> > > Hi Rusty,
> > > 
> > > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > > 
> > > drivers/acpi/osl.c: In function 'bind_to_cpu0':
> > > drivers/acpi/osl.c:194: error: implicit declaration of function 'set_cpus_allowed'

Still getting this ...

> > Here's a patch to fix this.  Since Linus' tree still contains instances
> > of set_cpus_allowed(), I'm guessing this patch should be added to the rr
> > tree?

Since set_cpus_allowed_ptr() aleeady exists in Linus' tree, you could put
that patch in your tree, Bjorn.

> Yep, my series removes it, at least for CONFIG_CPUMASK_OFFSTACK=y.

So one of you (at least) should apply that patch to your tree!  Please?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: rr tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]

On Mon, 10 Aug 2009 13:55:46 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Tue, 4 Aug 2009 08:48:26 +0930 Rusty Russell <rusty@rustcorp.com.au> wrote:
> >
> > On Tue, 4 Aug 2009 05:52:27 am Bjorn Helgaas wrote:
> > > On Sunday 02 August 2009 09:32:03 pm Stephen Rothwell wrote:
> > > > Hi Rusty,
> > > > 
> > > > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > > > 
> > > > drivers/acpi/osl.c: In function 'bind_to_cpu0':
> > > > drivers/acpi/osl.c:194: error: implicit declaration of function 'set_cpus_allowed'
> 
> Still getting this ...
> 
> > > Here's a patch to fix this.  Since Linus' tree still contains instances
> > > of set_cpus_allowed(), I'm guessing this patch should be added to the rr
> > > tree?
> 
> Since set_cpus_allowed_ptr() aleeady exists in Linus' tree, you could put
> that patch in your tree, Bjorn.

Actually "Len", sorry.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: rr tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

Hi Rusty,

Today's linux-next build (arm realview-smp_defconfig) failed like this:

arch/arm/kernel/smp.c: In function 'flush_tlb_mm':
arch/arm/kernel/smp.c:646: error: lvalue required as unary '&' operand
arch/arm/kernel/smp.c: In function 'flush_tlb_page':
arch/arm/kernel/smp.c:657: error: lvalue required as unary '&' operand
arch/arm/kernel/smp.c: In function 'flush_tlb_range':
arch/arm/kernel/smp.c:680: error: lvalue required as unary '&' operand

Caused by commit e97df8b735e20500a1d6a3743bef153869c472d3
("cpumask:use-mm_cpumask-arm").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: rr tree build failure

[Rusty Russell]

On Tue, 23 Jun 2009 03:44:16 pm Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next build (arm realview-smp_defconfig) failed like this:
>
> arch/arm/kernel/smp.c: In function 'flush_tlb_mm':
> arch/arm/kernel/smp.c:646: error: lvalue required as unary '&' operand
> arch/arm/kernel/smp.c: In function 'flush_tlb_page':
> arch/arm/kernel/smp.c:657: error: lvalue required as unary '&' operand
> arch/arm/kernel/smp.c: In function 'flush_tlb_range':
> arch/arm/kernel/smp.c:680: error: lvalue required as unary '&' operand

Dumb typo + cut & paste.

Fixed,
Rusty.

Re: linux-next: rr tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

Hi Rusty,

On Wed, 24 Jun 2009 12:54:24 +0930 Rusty Russell <rusty@rustcorp.com.au> wrote:
>
> Dumb typo + cut & paste.
> 
> Fixed,

Thanks, I will pick it up tomorrow.  For today, I have reverted
"cpumask:use-mm_cpumask-arm".

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: rr tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]

Hi Rusty,

Today's linux-next build (sparc64 defconfig) failed like this:

arch/sparc/mm/init_64.c: In function 'paging_init':
arch/sparc/mm/init_64.c:1802: error: 'CPU_MASK_ALL_PTR' undeclared (first use in this function)
arch/sparc/kernel/smp_64.c: In function 'setup_per_cpu_areas':
arch/sparc/kernel/smp_64.c:1541: error: 'CPU_MASK_ALL_PTR' undeclared (first use in this function)

Caused by commit 3360ebad15b16eac7b0205595d6fe561716725c5
("cpumask:remove-CPU_MASK_ALL_PTR") from the rr tree interacting with
commits 21bc149d59288fe43d1ba18a59d874ba6a5f1db9 ("sparc64: Make
mdesc_fill_in_cpu_data take a cpumask_t pointer") and
63750a3dc53a87a1f5ca42101ea88578b934ab52 ("sparc64: Defer cpu_data()
setup until end of per-cpu data initialization") from the sparc tree.

Rusty, I assume that there is something that Dave can use in the sparc
tree already instead of CPU_MASK_ALL_PTR (cpu_all_mask?).

I have reverted the rr tree patch for today - after reverting these other
patches as well:

cpumask:move-obsolete-functions-to-end-of-header
cpumask:remove-unused-deprecated-functions
cpumask:remove-cpu_mask_all

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: rr tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]

Hi Rusty, Dave,

On Mon, 15 Jun 2009 16:40:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (sparc64 defconfig) failed like this:
> 
> arch/sparc/mm/init_64.c: In function 'paging_init':
> arch/sparc/mm/init_64.c:1802: error: 'CPU_MASK_ALL_PTR' undeclared (first use in this function)
> arch/sparc/kernel/smp_64.c: In function 'setup_per_cpu_areas':
> arch/sparc/kernel/smp_64.c:1541: error: 'CPU_MASK_ALL_PTR' undeclared (first use in this function)
> 
> Caused by commit 3360ebad15b16eac7b0205595d6fe561716725c5
> ("cpumask:remove-CPU_MASK_ALL_PTR") from the rr tree interacting with
> commits 21bc149d59288fe43d1ba18a59d874ba6a5f1db9 ("sparc64: Make
> mdesc_fill_in_cpu_data take a cpumask_t pointer") and
> 63750a3dc53a87a1f5ca42101ea88578b934ab52 ("sparc64: Defer cpu_data()
> setup until end of per-cpu data initialization") from the sparc tree.
> 
> Rusty, I assume that there is something that Dave can use in the sparc
> tree already instead of CPU_MASK_ALL_PTR (cpu_all_mask?).

OK, senility is definitely setting in! :-)  This is the same failure we
had on Friday for which I sent a patch ...  Dave, can you apply that to
the sparc tree?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: rr tree build failure

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 15 Jun 2009 17:26:40 +1000

> OK, senility is definitely setting in! :-)  This is the same failure we
> had on Friday for which I sent a patch ...  Dave, can you apply that to
> the sparc tree?

Sorry, slipped through the cracks.  Could you please send me
a fresh copy of that patch?

Thanks!

Re: linux-next: rr tree build failure

[Rusty Russell]

On Mon, 15 Jun 2009 04:10:22 pm Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next build (sparc64 defconfig) failed like this:
>
> arch/sparc/mm/init_64.c: In function 'paging_init':
> arch/sparc/mm/init_64.c:1802: error: 'CPU_MASK_ALL_PTR' undeclared (first
> use in this function) arch/sparc/kernel/smp_64.c: In function
> 'setup_per_cpu_areas':
> arch/sparc/kernel/smp_64.c:1541: error: 'CPU_MASK_ALL_PTR' undeclared
> (first use in this function)
>
...
> Rusty, I assume that there is something that Dave can use in the sparc
> tree already instead of CPU_MASK_ALL_PTR (cpu_all_mask?).

cpu_all_mask, yes.

I have this great patch someone sent me :)

Thanks,
Rusty.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 12 Jun 2009 18:43:54 +1000
Subject: [PATCH] sparc: replace uses of CPU_MASK_ALL_PTR

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/sparc/kernel/smp_64.c |    2 +-
 arch/sparc/mm/init_64.c    |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/sparc/kernel/smp_64.c b/arch/sparc/kernel/smp_64.c
index 1de47d2..f3a83b0 100644
--- a/arch/sparc/kernel/smp_64.c
+++ b/arch/sparc/kernel/smp_64.c
@@ -1538,5 +1538,5 @@ void __init setup_per_cpu_areas(void)
 
 	of_fill_in_cpu_data();
 	if (tlb_type == hypervisor)
-		mdesc_fill_in_cpu_data(CPU_MASK_ALL_PTR);
+		mdesc_fill_in_cpu_data(cpu_all_mask);
 }
diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index b5a5932..ca92e2f 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -1799,7 +1799,7 @@ void __init paging_init(void)
 
 	if (tlb_type == hypervisor) {
 		sun4v_mdesc_init();
-		mdesc_populate_present_mask(CPU_MASK_ALL_PTR);
+		mdesc_populate_present_mask(cpu_all_mask);
 	}
 
 	/* Once the OF device tree and MDESC have been setup, we know
-- 
1.6.3.1

linux-next: rr tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

Hi Rusty,

Today's linux-next build (powerpc allnoconfig) failed like this:

lib/extable.c: In function 'trim_init_extable':
lib/extable.c:50: error: dereferencing pointer to incomplete type
lib/extable.c:50: error: implicit declaration of function 'within_module_init'
lib/extable.c:50: error: dereferencing pointer to incomplete type
lib/extable.c:51: error: dereferencing pointer to incomplete type
lib/extable.c:52: error: dereferencing pointer to incomplete type
lib/extable.c:55: error: dereferencing pointer to incomplete type
lib/extable.c:56: error: dereferencing pointer to incomplete type
lib/extable.c:56: error: dereferencing pointer to incomplete type
lib/extable.c:57: error: dereferencing pointer to incomplete type

Caused by commit 07c674557e43c27d4e7243a35b9ea030b09e3c3d ("module: trim
exception table on init free") which I have reverted for today.

This is a build without CONFIG_MODULE.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: rr tree build failure

[Rusty Russell]

On Tue, 9 Jun 2009 07:42:05 pm Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next build (powerpc allnoconfig) failed like this:
>
> lib/extable.c: In function 'trim_init_extable':
> lib/extable.c:50: error: dereferencing pointer to incomplete type
> lib/extable.c:50: error: implicit declaration of function
..
> This is a build without CONFIG_MODULE.

Ah, my bad.  I'll wrap this and test this config too.

Thanks,
Rusty.

Re: linux-next: rr tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 334 bytes --]

Hi Rusty,

On Wed, 10 Jun 2009 16:56:46 +0930 Rusty Russell <rusty@rustcorp.com.au> wrote:
>
> Ah, my bad.  I'll wrap this and test this config too.

Thanks.  I will revert that commit from today's linux-next as well.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: rr tree build failure

[Rusty Russell]

On Saturday 22 November 2008 05:04:03 Greg KH wrote:
> On Fri, Nov 21, 2008 at 09:28:51PM +1030, Rusty Russell wrote:
> > Greg, here's the complete patch I have now:
> >
> > Subject: USB: Use core_param.
> >
> > Found this when I changed args to __module_param_call.  We now have
> > core_param for exactly this.
> >
> > This reverts to the 2005 (pre- aafbf24a) behaviour where "nousb" was
> > not a module parameter, just a kernel command line parameter.  That's
> > more sensible anyway.
>
...
> No, we need to keep that module parameter please, some distros and users
> rely on it.

Fair enough.  Patch below does this as moduleparam.h suggests.

It still means that the paremeter appears in 
/sys/module/kernel/parameters/nousb OR
/sys/module/usbcore/parameters/nousb.

FYI, if Pete had discovered this __setup issue today, the correct fix would
be:
1) core_param(nousb) for backwards compat.
2) module_param(disable) for modern users who want module/in-built symmetry
   (ie. boot cmdline "usbcore.disable", and "modprobe usbcore disable")


USB: Don't use __module_param_call

Found this when I changed args to __module_param_call.  We now have
core_param for exactly this, but Greg assures me "nousb" is used as a
module parameter, using the method suggested in moduleparam.h will
have to do.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Pete Zaitcev <zaitcev@redhat.com>
---
 drivers/usb/core/usb.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -962,9 +962,6 @@ void usb_buffer_unmap_sg(const struct us
 }
 EXPORT_SYMBOL_GPL(usb_buffer_unmap_sg);
 
-/* format to disable USB on kernel command line is: nousb */
-__module_param_call("", nousb, param_set_bool, param_get_bool, &nousb, 0444);
-
 /*
  * for external read access to <nousb>
  */
@@ -1052,6 +1049,11 @@ static void __exit usb_exit(void)
 	ksuspend_usb_cleanup();
 }
 
+/* To disable USB, kernel command line is 'nousb' not 'usbcore.nousb' */
+#undef MODULE_PARAM_PREFIX
+#define MODULE_PARAM_PREFIX
+module_param(nousb, bool, 0444);
+
 subsys_initcall(usb_init);
 module_exit(usb_exit);
 MODULE_LICENSE("GPL");

Re: linux-next: rr tree build failure

[Greg KH]

On Sat, Nov 22, 2008 at 01:01:06PM +1030, Rusty Russell wrote:
> On Saturday 22 November 2008 05:04:03 Greg KH wrote:
> > On Fri, Nov 21, 2008 at 09:28:51PM +1030, Rusty Russell wrote:
> > > Greg, here's the complete patch I have now:
> > >
> > > Subject: USB: Use core_param.
> > >
> > > Found this when I changed args to __module_param_call.  We now have
> > > core_param for exactly this.
> > >
> > > This reverts to the 2005 (pre- aafbf24a) behaviour where "nousb" was
> > > not a module parameter, just a kernel command line parameter.  That's
> > > more sensible anyway.
> >
> ...
> > No, we need to keep that module parameter please, some distros and users
> > rely on it.
> 
> Fair enough.  Patch below does this as moduleparam.h suggests.
> 
> It still means that the paremeter appears in 
> /sys/module/kernel/parameters/nousb OR
> /sys/module/usbcore/parameters/nousb.

What's the "OR" part?  What determines where it goes?

> FYI, if Pete had discovered this __setup issue today, the correct fix would
> be:
> 1) core_param(nousb) for backwards compat.
> 2) module_param(disable) for modern users who want module/in-built symmetry
>    (ie. boot cmdline "usbcore.disable", and "modprobe usbcore disable")
> 
> 
> USB: Don't use __module_param_call
> 
> Found this when I changed args to __module_param_call.  We now have
> core_param for exactly this, but Greg assures me "nousb" is used as a
> module parameter, using the method suggested in moduleparam.h will
> have to do.

Is there a real reason why we need to change this at all?

> +/* To disable USB, kernel command line is 'nousb' not 'usbcore.nousb' */
> +#undef MODULE_PARAM_PREFIX
> +#define MODULE_PARAM_PREFIX
> +module_param(nousb, bool, 0444);

That undef seems hacky beyond belief.  How would one know to do this?

thanks,

greg k-h

Re: linux-next: rr tree build failure

[Pete Zaitcev]

On Fri, 21 Nov 2008 22:41:32 -0800, Greg KH <gregkh@suse.de> wrote:

> > FYI, if Pete had discovered this __setup issue today, the correct fix would
> > be:
> > 1) core_param(nousb) for backwards compat.
> > 2) module_param(disable) for modern users who want module/in-built symmetry
> >    (ie. boot cmdline "usbcore.disable", and "modprobe usbcore disable")

> Is there a real reason why we need to change this at all?

As far as I know, in Fedora "nousb" is never used as a module parameter.
It came about because interrupt tables are sometimes bad and once
a request_irq() is done in an HCD, there's an interrupt storm. So,
the "nousb" is mostly used in the SysLinux's command line, rarely
in the real command line, and never in /etc/modprobe.conf.
I'm adding Jeremy to cc: for confirmation.

I think it would be good to try and drop "nousb" option in Fedora 11.
The conflict with "nousbstorage" would resolve itself too if we do.

-- Pete

Re: linux-next: rr tree build failure

[Rusty Russell]

On Sunday 23 November 2008 03:59:52 Pete Zaitcev wrote:
> On Fri, 21 Nov 2008 22:41:32 -0800, Greg KH <gregkh@suse.de> wrote:
> > > FYI, if Pete had discovered this __setup issue today, the correct fix
> > > would be:
> > > 1) core_param(nousb) for backwards compat.
> > > 2) module_param(disable) for modern users who want module/in-built
> > > symmetry (ie. boot cmdline "usbcore.disable", and "modprobe usbcore
> > > disable")
> >
> > Is there a real reason why we need to change this at all?

You're the only __module_param_call user outside moduleparam.h, and so an 
unrelated patch broke USB. :(

> As far as I know, in Fedora "nousb" is never used as a module parameter.
> It came about because interrupt tables are sometimes bad and once
> a request_irq() is done in an HCD, there's an interrupt storm. So,
> the "nousb" is mostly used in the SysLinux's command line, rarely
> in the real command line, and never in /etc/modprobe.conf.
> I'm adding Jeremy to cc: for confirmation.
>
> I think it would be good to try and drop "nousb" option in Fedora 11.
> The conflict with "nousbstorage" would resolve itself too if we do.

My original patch simply turned it into a core_param (ie. not valid as a 
module parameter).  If this had existed in 2005, it would have been the right 
answer.

If there's any chance of it actually breaking, let's leave it as a module 
parameter too (which is what the patch I sent does).

Thanks,
Rusty.

Re: linux-next: rr tree build failure

[Rusty Russell]

On Saturday 22 November 2008 17:11:32 Greg KH wrote:
> On Sat, Nov 22, 2008 at 01:01:06PM +1030, Rusty Russell wrote:
> > Fair enough.  Patch below does this as moduleparam.h suggests.
> >
> > It still means that the paremeter appears in
> > /sys/module/kernel/parameters/nousb OR
> > /sys/module/usbcore/parameters/nousb.
>
> What's the "OR" part?  What determines where it goes?

Whether usbcore is a module or not, of course.

> > +/* To disable USB, kernel command line is 'nousb' not 'usbcore.nousb' */
> > +#undef MODULE_PARAM_PREFIX
> > +#define MODULE_PARAM_PREFIX
> > +module_param(nousb, bool, 0444);
>
> That undef seems hacky beyond belief.

*Exactly*.  And while you're not the first person to do this, you're the one 
one to use it for code which can be a module :(

> How would one know to do this?

The same way Pete found __module_param_call, by reading the header:

 /* You can override this manually, but generally this should match the
    module name. */
 #ifdef MODULE
 #define MODULE_PARAM_PREFIX /* empty */
 #else
 #define MODULE_PARAM_PREFIX KBUILD_MODNAME "."
 #endif

Cheers,
Rusty.

Re: linux-next: rr tree build failure

[Pete Zaitcev]

On Fri, 21 Nov 2008 22:41:32 -0800, Greg KH <gregkh@suse.de> wrote:

> > > > This reverts to the 2005 (pre- aafbf24a) behaviour where "nousb" was
> > > > not a module parameter, just a kernel command line parameter.  That's
> > > > more sensible anyway.

By the way, I floated the idea to remove "nousb" altogether on fedora-devel.
Alan Cox replied that he has an actual box that requires it,
because of a bug in SMM BIOS... Imagine my surprise. I think we're
stuck with "nousb" for a little while still.

-- Pete