Re: linux-next: build failure after merge of the modules tree

[Masahiro Yamada]

On Wed, Feb 10, 2021 at 5:37 PM Masahiro Yamada  wrote:
>
> On Wed, Feb 10, 2021 at 5:06 PM Jessica Yu  wrote:
> >
> > +++ Stephen Rothwell [10/02/21 08:50 +1100]:
> > >Hi Jessica,
> > >
> > >On Tue, 9 Feb 2021 16:16:20 +0100 Jessica Yu  wrote:
> > >>
> > >> Hmm, these errors don't look like it's related to that particular 
> > >> commit. I was
> > >
> > >I found this commit by bisection and then tested by reverting it.
> > >
> > >Before this commit, CONFIG_TRIM_UNUSED_KSYMS would not be set in the
> > >allyesconfig build because CONFIG_UNUSED_SYMBOLS was set.  After this
> > >commit, CONFIG_TRIM_UNUSED_KSYMS will be set in the allyesconfig build.
> >
> > Ah, that makes sense then. I would get the error on powerpc whenever
> > CONFIG_TRIM_UNUSED_KSYMS was enabled.
> >
> > >> able to reproduce these weird autoksym errors even without any 
> > >> modules-next
> > >> patches applied, and on a clean v5.11-rc7 tree. To reproduce it,
> > >> CONFIG_TRIM_UNUSED_KSYMS needs to be enabled. I guess that's why we run 
> > >> into
> > >> these errors with allyesconfig. I used a gcc-7 ppc64le cross compiler 
> > >> and got
> > >> the same compiler warnings. It seems to not compile on powerpc properly 
> > >> because
> > >> it looks like some symbols have an extra dot "." prefix, for example in
> > >> kthread.o:
> > >>
> > >> 168: 031824 NOTYPE  GLOBAL DEFAULT6 
> > >> kthread_create_worker
> > >> 169: 1d90   104 FUNCGLOBAL DEFAULT1 
> > >> .kthread_create_worker
> > >> 170: 033024 NOTYPE  GLOBAL DEFAULT6 
> > >> kthread_create_worker_on_cpu
> > >> 171: 1e0088 FUNCGLOBAL DEFAULT1 
> > >> .kthread_create_worker_on_cpu
> > >> 172: 034824 NOTYPE  GLOBAL DEFAULT6 
> > >> kthread_queue_work
> > >> 173: 1e60   228 FUNCGLOBAL DEFAULT1 
> > >> .kthread_queue_work
> > >>
> > >> So I suppose this dot prefix is specific to powerpc. From the ppc64 elf 
> > >> abi docs:
> > >>
> > >>  Symbol names with a dot (.) prefix are reserved for holding entry 
> > >> point
> > >>  addresses. The value of a symbol named ".FN", if it exists, is the 
> > >> entry point
> > >>  of the function "FN".
> > >>
> > >> I guess the presence of the extra dot symbols is confusing
> > >> scripts/gen_autoksyms.sh, so we get the dot symbols in autoksyms.h, 
> > >> which the
> > >> preprocessor doesn't like. I am wondering how this was never caught 
> > >> until now
> > >> and also now curious if this feature was ever functional on powerpc..
> > >
> > >Which feature?
> >
> > Sorry, by "feature" I meant CONFIG_TRIM_UNUSED_KSYMS. This config
> > option was introduced around v4.7. If simply enabling it produces
> > these compilation errors I was wondering if it ever built properly on
> > powerpc.
> >
> > Thanks,
> >
> > Jessica
>
>
> Thanks for the report.
>
> I think the following will fix the issue,
> but modpost needs fixing too.
>
>
> diff --git a/scripts/gen_autoksyms.sh b/scripts/gen_autoksyms.sh
> index 16c0b2ddaa4c..996a7109167b 100755
> --- a/scripts/gen_autoksyms.sh
> +++ b/scripts/gen_autoksyms.sh
> @@ -44,7 +44,7 @@ sed 's/ko$/mod/' $modlist |
>  xargs -n1 sed -n -e '2{s/ /\n/g;/^$/!p;}' -- |
>  cat - "$ksym_wl" |
>  sort -u |
> -sed -e 's/\(.*\)/#define __KSYM_\1 1/' >> "$output_file"
> +sed -e 's/^\.\{,1\}\(.*\)/#define __KSYM_\1 1/' >> "$output_file"
>
>  # Special case for modversions (see modpost.c)
>  if [ -n "$CONFIG_MODVERSIONS" ]; then
> m



After some more tests, I noticed the code above was not correct.
I still saw a lot of modpost errors.

ERROR: modpost: "_mcount" [arch/powerpc/oprofile/oprofile.ko] undefined!
ERROR: modpost: "._mcount" [arch/powerpc/oprofile/oprofile.ko] undefined!


I just posted a patch, which fixes the error as far as I tested.
https://patchwork.kernel.org/project/linux-kbuild/patch/20210211061416.3747231-1-masahi...@kernel.org/



-- 
Best Regards
Masahiro Yamada

Re: linux-next: build failure after merge of the modules tree

[Jessica Yu]

+++ Stephen Rothwell [10/02/21 23:21 +1100]:

Hi Jessica,

On Wed, 10 Feb 2021 09:06:48 +0100 Jessica Yu  wrote:


Sorry, by "feature" I meant CONFIG_TRIM_UNUSED_KSYMS. This config
option was introduced around v4.7. If simply enabling it produces
these compilation errors I was wondering if it ever built properly on
powerpc.


Ah, of course.  So for a quick fix, you could revert just the changes
to lib/Kconfig and all the defconfigs.  That way all the UNUSED_SYMBOLS
infrastructure is still removed, but TRIM_UNUSED_KSYMS remains (un)set
whenever it used to be (un)set and that could then be cleaned up in a
followup patch set per architecture when we know it works.


Hi Stephen,

What's maybe simpler is marking this as BROKEN on PPC64 as a temporary
fix for linux-next until Masahiro's patch (the real fix) is posted. I
think the real problem is that TRIM_UNUSED_KSYMS was pretty much
hiding behind UNUSED_SYMBOLS=y until it finally got removed. Anyway
the main point is that TRIM_UNUSED_KSYMS=y shouldn't be breaking any
builds. I've pushed this change and hope that won't break linux-next now.

---

From 1fa67f8391acb88a54e7defe6b73f8f171450f4a Mon Sep 17 00:00:00 2001
From: Jessica Yu 
Date: Wed, 10 Feb 2021 16:59:53 +0100
Subject: [PATCH] module: mark TRIM_UNUSED_KSYMS as BROKEN on powerpc

Commit 367948220fce, which removed CONFIG_UNUSED_SYMBOLS, unraveled the
TRIM_UNUSED_KSYMS config option to be generally available without depending
on CONFIG_UNUSED_SYMBOLS=y. With CONFIG_UNUSED_SYMBOLS gone, this means
allyesconfig will now select this option without being "behind"
CONFIG_UNUSED_SYMBOLS. Unfortunately, this revealed some underlying build
issues on powerpc. When CONFIG_TRIM_UNUSED_KSYMS is enabled on powerpc, the
build would fail like this:

In file included from include/linux/export.h:123,
 from include/linux/linkage.h:7,
 from arch/powerpc/include/asm/unistd.h:18,
 from :2:
./include/generated/autoksyms.h:5:9: warning: missing whitespace after the
macro name
5 | #define __KSYM_.HT_update_self_and_peer_setting 1
  | ^~~
./include/generated/autoksyms.h:6:9: warning: missing whitespace after the
macro name
6 | #define __KSYM_.RemovePeerTS 1
  | ^~~
./include/generated/autoksyms.h:6: warning: "__KSYM_" redefined
6 | #define __KSYM_.RemovePeerTS 1
  |
./include/generated/autoksyms.h:5: note: this is the location of the
previous definition

This is due to the addition of a dot "." prefix to some symbols that is
specific to powerpc, which confuses the gen_autoksyms script.

This is a temporary workaround for linux-next until gen_autoksyms and
modpost gets fixed.

Link: http://lore.kernel.org/r/20210209210843.3af66...@canb.auug.org.au
Signed-off-by: Jessica Yu 
---
 init/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/init/Kconfig b/init/Kconfig
index 11b803b45c19..e4504a04b601 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -2264,6 +2264,7 @@ config MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS
 
 config TRIM_UNUSED_KSYMS

bool "Trim unused exported kernel symbols"
+   depends on !PPC64 || BROKEN
help
  The kernel and some modules make many symbols available for
  other modules to use via EXPORT_SYMBOL() and variants. Depending

Re: linux-next: build failure after merge of the modules tree

[Stephen Rothwell]

Hi Jessica,

On Wed, 10 Feb 2021 09:06:48 +0100 Jessica Yu  wrote:
> 
> Sorry, by "feature" I meant CONFIG_TRIM_UNUSED_KSYMS. This config
> option was introduced around v4.7. If simply enabling it produces
> these compilation errors I was wondering if it ever built properly on
> powerpc.

Ah, of course.  So for a quick fix, you could revert just the changes
to lib/Kconfig and all the defconfigs.  That way all the UNUSED_SYMBOLS
infrastructure is still removed, but TRIM_UNUSED_KSYMS remains (un)set
whenever it used to be (un)set and that could then be cleaned up in a
followup patch set per architecture when we know it works.
-- 
Cheers,
Stephen Rothwell


pgpWNMgqkFzCv.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the modules tree

[Masahiro Yamada]

On Wed, Feb 10, 2021 at 5:06 PM Jessica Yu  wrote:
>
> +++ Stephen Rothwell [10/02/21 08:50 +1100]:
> >Hi Jessica,
> >
> >On Tue, 9 Feb 2021 16:16:20 +0100 Jessica Yu  wrote:
> >>
> >> Hmm, these errors don't look like it's related to that particular commit. 
> >> I was
> >
> >I found this commit by bisection and then tested by reverting it.
> >
> >Before this commit, CONFIG_TRIM_UNUSED_KSYMS would not be set in the
> >allyesconfig build because CONFIG_UNUSED_SYMBOLS was set.  After this
> >commit, CONFIG_TRIM_UNUSED_KSYMS will be set in the allyesconfig build.
>
> Ah, that makes sense then. I would get the error on powerpc whenever
> CONFIG_TRIM_UNUSED_KSYMS was enabled.
>
> >> able to reproduce these weird autoksym errors even without any modules-next
> >> patches applied, and on a clean v5.11-rc7 tree. To reproduce it,
> >> CONFIG_TRIM_UNUSED_KSYMS needs to be enabled. I guess that's why we run 
> >> into
> >> these errors with allyesconfig. I used a gcc-7 ppc64le cross compiler and 
> >> got
> >> the same compiler warnings. It seems to not compile on powerpc properly 
> >> because
> >> it looks like some symbols have an extra dot "." prefix, for example in
> >> kthread.o:
> >>
> >> 168: 031824 NOTYPE  GLOBAL DEFAULT6 
> >> kthread_create_worker
> >> 169: 1d90   104 FUNCGLOBAL DEFAULT1 
> >> .kthread_create_worker
> >> 170: 033024 NOTYPE  GLOBAL DEFAULT6 
> >> kthread_create_worker_on_cpu
> >> 171: 1e0088 FUNCGLOBAL DEFAULT1 
> >> .kthread_create_worker_on_cpu
> >> 172: 034824 NOTYPE  GLOBAL DEFAULT6 
> >> kthread_queue_work
> >> 173: 1e60   228 FUNCGLOBAL DEFAULT1 
> >> .kthread_queue_work
> >>
> >> So I suppose this dot prefix is specific to powerpc. From the ppc64 elf 
> >> abi docs:
> >>
> >>  Symbol names with a dot (.) prefix are reserved for holding entry 
> >> point
> >>  addresses. The value of a symbol named ".FN", if it exists, is the 
> >> entry point
> >>  of the function "FN".
> >>
> >> I guess the presence of the extra dot symbols is confusing
> >> scripts/gen_autoksyms.sh, so we get the dot symbols in autoksyms.h, which 
> >> the
> >> preprocessor doesn't like. I am wondering how this was never caught until 
> >> now
> >> and also now curious if this feature was ever functional on powerpc..
> >
> >Which feature?
>
> Sorry, by "feature" I meant CONFIG_TRIM_UNUSED_KSYMS. This config
> option was introduced around v4.7. If simply enabling it produces
> these compilation errors I was wondering if it ever built properly on
> powerpc.
>
> Thanks,
>
> Jessica


Thanks for the report.

I think the following will fix the issue,
but modpost needs fixing too.


diff --git a/scripts/gen_autoksyms.sh b/scripts/gen_autoksyms.sh
index 16c0b2ddaa4c..996a7109167b 100755
--- a/scripts/gen_autoksyms.sh
+++ b/scripts/gen_autoksyms.sh
@@ -44,7 +44,7 @@ sed 's/ko$/mod/' $modlist |
 xargs -n1 sed -n -e '2{s/ /\n/g;/^$/!p;}' -- |
 cat - "$ksym_wl" |
 sort -u |
-sed -e 's/\(.*\)/#define __KSYM_\1 1/' >> "$output_file"
+sed -e 's/^\.\{,1\}\(.*\)/#define __KSYM_\1 1/' >> "$output_file"

 # Special case for modversions (see modpost.c)
 if [ -n "$CONFIG_MODVERSIONS" ]; then
m




I will post two patches with some commit log
after some testing.
(one for gen_autoksyms.sh and the other for modpost).





-- 
Best Regards
Masahiro Yamada

Re: linux-next: build failure after merge of the modules tree

[Jessica Yu]

+++ Stephen Rothwell [10/02/21 08:50 +1100]:

Hi Jessica,

On Tue, 9 Feb 2021 16:16:20 +0100 Jessica Yu  wrote:


Hmm, these errors don't look like it's related to that particular commit. I was


I found this commit by bisection and then tested by reverting it.

Before this commit, CONFIG_TRIM_UNUSED_KSYMS would not be set in the
allyesconfig build because CONFIG_UNUSED_SYMBOLS was set.  After this
commit, CONFIG_TRIM_UNUSED_KSYMS will be set in the allyesconfig build.


Ah, that makes sense then. I would get the error on powerpc whenever
CONFIG_TRIM_UNUSED_KSYMS was enabled.


able to reproduce these weird autoksym errors even without any modules-next
patches applied, and on a clean v5.11-rc7 tree. To reproduce it,
CONFIG_TRIM_UNUSED_KSYMS needs to be enabled. I guess that's why we run into
these errors with allyesconfig. I used a gcc-7 ppc64le cross compiler and got
the same compiler warnings. It seems to not compile on powerpc properly because
it looks like some symbols have an extra dot "." prefix, for example in
kthread.o:

168: 031824 NOTYPE  GLOBAL DEFAULT6 
kthread_create_worker
169: 1d90   104 FUNCGLOBAL DEFAULT1 
.kthread_create_worker
170: 033024 NOTYPE  GLOBAL DEFAULT6 
kthread_create_worker_on_cpu
171: 1e0088 FUNCGLOBAL DEFAULT1 
.kthread_create_worker_on_cpu
172: 034824 NOTYPE  GLOBAL DEFAULT6 kthread_queue_work
173: 1e60   228 FUNCGLOBAL DEFAULT1 .kthread_queue_work

So I suppose this dot prefix is specific to powerpc. From the ppc64 elf abi 
docs:

 Symbol names with a dot (.) prefix are reserved for holding entry point
 addresses. The value of a symbol named ".FN", if it exists, is the entry 
point
 of the function "FN".

I guess the presence of the extra dot symbols is confusing
scripts/gen_autoksyms.sh, so we get the dot symbols in autoksyms.h, which the
preprocessor doesn't like. I am wondering how this was never caught until now
and also now curious if this feature was ever functional on powerpc..


Which feature?


Sorry, by "feature" I meant CONFIG_TRIM_UNUSED_KSYMS. This config
option was introduced around v4.7. If simply enabling it produces
these compilation errors I was wondering if it ever built properly on
powerpc.

Thanks,

Jessica

Re: linux-next: build failure after merge of the modules tree

[Stephen Rothwell]

Hi Jessica,

On Tue, 9 Feb 2021 16:16:20 +0100 Jessica Yu  wrote:
>
> Hmm, these errors don't look like it's related to that particular commit. I 
> was

I found this commit by bisection and then tested by reverting it.

Before this commit, CONFIG_TRIM_UNUSED_KSYMS would not be set in the
allyesconfig build because CONFIG_UNUSED_SYMBOLS was set.  After this
commit, CONFIG_TRIM_UNUSED_KSYMS will be set in the allyesconfig build.

> able to reproduce these weird autoksym errors even without any modules-next
> patches applied, and on a clean v5.11-rc7 tree. To reproduce it,
> CONFIG_TRIM_UNUSED_KSYMS needs to be enabled. I guess that's why we run into
> these errors with allyesconfig. I used a gcc-7 ppc64le cross compiler and got
> the same compiler warnings. It seems to not compile on powerpc properly 
> because
> it looks like some symbols have an extra dot "." prefix, for example in
> kthread.o:
> 
> 168: 031824 NOTYPE  GLOBAL DEFAULT6 
> kthread_create_worker
> 169: 1d90   104 FUNCGLOBAL DEFAULT1 
> .kthread_create_worker
> 170: 033024 NOTYPE  GLOBAL DEFAULT6 
> kthread_create_worker_on_cpu
> 171: 1e0088 FUNCGLOBAL DEFAULT1 
> .kthread_create_worker_on_cpu
> 172: 034824 NOTYPE  GLOBAL DEFAULT6 kthread_queue_work
> 173: 1e60   228 FUNCGLOBAL DEFAULT1 
> .kthread_queue_work
> 
> So I suppose this dot prefix is specific to powerpc. From the ppc64 elf abi 
> docs:
> 
>  Symbol names with a dot (.) prefix are reserved for holding entry point
>  addresses. The value of a symbol named ".FN", if it exists, is the entry 
> point
>  of the function "FN".
> 
> I guess the presence of the extra dot symbols is confusing
> scripts/gen_autoksyms.sh, so we get the dot symbols in autoksyms.h, which the
> preprocessor doesn't like. I am wondering how this was never caught until now
> and also now curious if this feature was ever functional on powerpc..

Which feature?

-- 
Cheers,
Stephen Rothwell


pgpXftwdacuDx.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the modules tree

[Christoph Hellwig]

On Tue, Feb 09, 2021 at 04:16:20PM +0100, Jessica Yu wrote:
> Hmm, these errors don't look like it's related to that particular commit. I 
> was
> able to reproduce these weird autoksym errors even without any modules-next
> patches applied, and on a clean v5.11-rc7 tree.

I OTOH can't reproduce it at all with either linux-next or module-next
and the powerpc allyesconfig..

Re: linux-next: build failure after merge of the modules tree

[Jessica Yu]

+++ Stephen Rothwell [09/02/21 21:08 +1100]:

Hi all,

After merging the modules tree, today's linux-next build (powerpc
allyesconfig) failed like this:

In file included from include/linux/export.h:123,
from include/linux/linkage.h:7,
from arch/powerpc/include/asm/unistd.h:18,
from :2:
./include/generated/autoksyms.h:5:9: warning: missing whitespace after the 
macro name
   5 | #define __KSYM_.HT_update_self_and_peer_setting 1
 | ^~~
./include/generated/autoksyms.h:6:9: warning: missing whitespace after the 
macro name
   6 | #define __KSYM_.RemovePeerTS 1
 | ^~~
./include/generated/autoksyms.h:6: warning: "__KSYM_" redefined
   6 | #define __KSYM_.RemovePeerTS 1
 |
./include/generated/autoksyms.h:5: note: this is the location of the previous 
definition

and on and on :-(

Caused by commit

 367948220fce ("module: remove EXPORT_UNUSED_SYMBOL*")

I have reverted that commit for today.


[ Adding Michael and Masahiro to CC ]

Hi Stephen,

Hmm, these errors don't look like it's related to that particular commit. I was
able to reproduce these weird autoksym errors even without any modules-next
patches applied, and on a clean v5.11-rc7 tree. To reproduce it,
CONFIG_TRIM_UNUSED_KSYMS needs to be enabled. I guess that's why we run into
these errors with allyesconfig. I used a gcc-7 ppc64le cross compiler and got
the same compiler warnings. It seems to not compile on powerpc properly because
it looks like some symbols have an extra dot "." prefix, for example in
kthread.o:

   168: 031824 NOTYPE  GLOBAL DEFAULT6 kthread_create_worker
   169: 1d90   104 FUNCGLOBAL DEFAULT1 
.kthread_create_worker
   170: 033024 NOTYPE  GLOBAL DEFAULT6 
kthread_create_worker_on_cpu
   171: 1e0088 FUNCGLOBAL DEFAULT1 
.kthread_create_worker_on_cpu
   172: 034824 NOTYPE  GLOBAL DEFAULT6 kthread_queue_work
   173: 1e60   228 FUNCGLOBAL DEFAULT1 .kthread_queue_work

So I suppose this dot prefix is specific to powerpc. From the ppc64 elf abi 
docs:

Symbol names with a dot (.) prefix are reserved for holding entry point
addresses. The value of a symbol named ".FN", if it exists, is the entry 
point
of the function "FN".

I guess the presence of the extra dot symbols is confusing
scripts/gen_autoksyms.sh, so we get the dot symbols in autoksyms.h, which the
preprocessor doesn't like. I am wondering how this was never caught until now
and also now curious if this feature was ever functional on powerpc..

Thanks,

Jessica

Re: linux-next: build failure after merge of the modules tree

[Rusty Russell]

Mark Brown  writes:
> Hi Rusty,
>
> After merging the modules tree, today's linux-next x86 allmodconfig build 
> (20151201) failed like this:
>
> /home/broonie/next/next/arch/x86/kernel/livepatch.c: In function 
> 'klp_write_module_reloc':
> /home/broonie/next/next/arch/x86/kernel/livepatch.c:75:22: error: 'struct 
> module' has no member named 'core_ro_size'
>   if (loc < core + mod->core_ro_size)

Yep, I missed that one.

I also missed an ARM case, so I'll rebase the tree (it's near the top
anyway).

Cheers,
Rusty.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Rusty Russell]

Mark Brown  writes:
> Hi Rusty,
>
> After merging the modules tree, today's linux-next x86 allmodconfig build 
> (20151201) failed like this:
>
> /home/broonie/next/next/arch/x86/kernel/livepatch.c: In function 
> 'klp_write_module_reloc':
> /home/broonie/next/next/arch/x86/kernel/livepatch.c:75:22: error: 'struct 
> module' has no member named 'core_ro_size'
>   if (loc < core + mod->core_ro_size)

Yep, I missed that one.

I also missed an ARM case, so I'll rebase the tree (it's near the top
anyway).

Cheers,
Rusty.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Rusty Russell]

Stephen Rothwell  writes:
> Hi Rusty,
>
> After merging the modules tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from include/linux/kexec.h:26:0,
>  from include/linux/crash_dump.h:5,
>  from arch/powerpc/platforms/powernv/pci-ioda.c:16:
> include/linux/module.h:770:15: error: return type defaults to 'int' 
> [-Werror=return-type]

Thanks, this typo hit all archs which don't do RO module protection by
default.

Maybe PPC should do that?

I've fixed it (and some others found by 0-day) and rebased.

Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Rusty Russell]

Stephen Rothwell  writes:
> Hi Rusty,
>
> After merging the modules tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from include/linux/kexec.h:26:0,
>  from include/linux/crash_dump.h:5,
>  from arch/powerpc/platforms/powernv/pci-ioda.c:16:
> include/linux/module.h:770:15: error: return type defaults to 'int' 
> [-Werror=return-type]

Thanks, this typo hit all archs which don't do RO module protection by
default.

Maybe PPC should do that?

I've fixed it (and some others found by 0-day) and rebased.

Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Dan Streetman]

On Thu, Jun 25, 2015 at 2:54 AM, Stephen Rothwell  wrote:
> Hi Rusty,
>
> After merging the modules tree, today's linux-next build (powerpc
> allnoconfig) failed like this:

I promise I'll build with all[no|mod|yes]config next time! ;-)

Thanks for catching this one too.

>
> kernel/params.c:628:6: error: redefinition of 'kernel_param_lock'
>  void kernel_param_lock(struct module *mod)
>   ^
> In file included from include/linux/module.h:18:0,
>  from kernel/params.c:21:
> include/linux/moduleparam.h:246:20: note: previous definition of 
> 'kernel_param_lock' was here
>  static inline void kernel_param_lock(struct module *mod)
> ^
> kernel/params.c:633:6: error: redefinition of 'kernel_param_unlock'
>  void kernel_param_unlock(struct module *mod)
>   ^
> In file included from include/linux/module.h:18:0,
>  from kernel/params.c:21:
> include/linux/moduleparam.h:249:20: note: previous definition of 
> 'kernel_param_unlock' was here
>  static inline void kernel_param_unlock(struct module *mod)
> ^
>
> Caused by commit b51d23e4e9fe ("module: add per-module param_lock").
> This had not been tested with CONFIG_SYSFS not set.
>
> I have added the following patch for today (which may not be complete,
> but builds).

this is one way to handle it, but it will cause all modules to use the
built-in param_lock,
which (I don't think) is needed if there's no sysfs; another way would
be to elide the
param_lock entirely if !CONFIG_SYSFS.  I'll send a patch for that.

Rusty, is param locking needed if there is no sysfs?

>
> From: Stephen Rothwell 
> Date: Thu, 25 Jun 2015 16:38:51 +1000
> Subject: [PATCH] modules: clean up add per-module param_lock
>
> Signed-off-by: Stephen Rothwell 
> ---
>  include/linux/moduleparam.h | 9 -
>  1 file changed, 9 deletions(-)
>
> diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
> index c12f2147c350..428d7c25c383 100644
> --- a/include/linux/moduleparam.h
> +++ b/include/linux/moduleparam.h
> @@ -239,17 +239,8 @@ __check_old_set_param(int (*oldset)(const char *, struct 
> kernel_param *))
> return 0;
>  }
>
> -#ifdef CONFIG_SYSFS
>  extern void kernel_param_lock(struct module *mod);
>  extern void kernel_param_unlock(struct module *mod);
> -#else
> -static inline void kernel_param_lock(struct module *mod)
> -{
> -}
> -static inline void kernel_param_unlock(struct module *mod)
> -{
> -}
> -#endif
>
>  #ifndef MODULE
>  /**
> --
> 2.1.4
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Dan Streetman]

On Thu, Jun 25, 2015 at 2:54 AM, Stephen Rothwell s...@canb.auug.org.au wrote:
 Hi Rusty,

 After merging the modules tree, today's linux-next build (powerpc
 allnoconfig) failed like this:

I promise I'll build with all[no|mod|yes]config next time! ;-)

Thanks for catching this one too.


 kernel/params.c:628:6: error: redefinition of 'kernel_param_lock'
  void kernel_param_lock(struct module *mod)
   ^
 In file included from include/linux/module.h:18:0,
  from kernel/params.c:21:
 include/linux/moduleparam.h:246:20: note: previous definition of 
 'kernel_param_lock' was here
  static inline void kernel_param_lock(struct module *mod)
 ^
 kernel/params.c:633:6: error: redefinition of 'kernel_param_unlock'
  void kernel_param_unlock(struct module *mod)
   ^
 In file included from include/linux/module.h:18:0,
  from kernel/params.c:21:
 include/linux/moduleparam.h:249:20: note: previous definition of 
 'kernel_param_unlock' was here
  static inline void kernel_param_unlock(struct module *mod)
 ^

 Caused by commit b51d23e4e9fe (module: add per-module param_lock).
 This had not been tested with CONFIG_SYSFS not set.

 I have added the following patch for today (which may not be complete,
 but builds).

this is one way to handle it, but it will cause all modules to use the
built-in param_lock,
which (I don't think) is needed if there's no sysfs; another way would
be to elide the
param_lock entirely if !CONFIG_SYSFS.  I'll send a patch for that.

Rusty, is param locking needed if there is no sysfs?


 From: Stephen Rothwell s...@canb.auug.org.au
 Date: Thu, 25 Jun 2015 16:38:51 +1000
 Subject: [PATCH] modules: clean up add per-module param_lock

 Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
 ---
  include/linux/moduleparam.h | 9 -
  1 file changed, 9 deletions(-)

 diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
 index c12f2147c350..428d7c25c383 100644
 --- a/include/linux/moduleparam.h
 +++ b/include/linux/moduleparam.h
 @@ -239,17 +239,8 @@ __check_old_set_param(int (*oldset)(const char *, struct 
 kernel_param *))
 return 0;
  }

 -#ifdef CONFIG_SYSFS
  extern void kernel_param_lock(struct module *mod);
  extern void kernel_param_unlock(struct module *mod);
 -#else
 -static inline void kernel_param_lock(struct module *mod)
 -{
 -}
 -static inline void kernel_param_unlock(struct module *mod)
 -{
 -}
 -#endif

  #ifndef MODULE
  /**
 --
 2.1.4

 --
 Cheers,
 Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Stephen Rothwell]

Hi Dan,

On Thu, 25 Jun 2015 08:57:06 +1000 Stephen Rothwell  
wrote:
>
> On Wed, 24 Jun 2015 14:18:44 -0400 Dan Streetman  wrote:
> >
> > On Tue, Jun 23, 2015 at 9:37 PM, Stephen Rothwell  
> > wrote:
> > >
> > > After merging the modules tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > 
> > that's weird.  Are you sure it failed during allmodconfig?  I can see
> > why it would fail like that if CONFIG_MODULES ins't defined, which
> > I'll send a patch for...
> 
> Pretty sure - and, in any case, I don't do any CONFIG_MODULES=n builds
> between tree merges (only later in the day).  That is why I couldn't
> figure out what went wrong.
> 
> I will apply your patch today and see if that helps.

I built without your patch and it failed again, but applying your patch fixes 
it.

Rusty, you can consider this

Tested-by: Stephen Rothwell 

for "[PATCH] modules: only use mod->param_lock if CONFIG_MODULES"
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpZAvvYXZwgD.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the modules tree

[Stephen Rothwell]

Hi Dan,

On Wed, 24 Jun 2015 14:18:44 -0400 Dan Streetman  wrote:
>
> On Tue, Jun 23, 2015 at 9:37 PM, Stephen Rothwell  
> wrote:
> >
> > After merging the modules tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> 
> that's weird.  Are you sure it failed during allmodconfig?  I can see
> why it would fail like that if CONFIG_MODULES ins't defined, which
> I'll send a patch for...

Pretty sure - and, in any case, I don't do any CONFIG_MODULES=n builds
between tree merges (only later in the day).  That is why I couldn't
figure out what went wrong.

I will apply your patch today and see if that helps.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgppg89WDaTjH.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the modules tree

[Dan Streetman]

On Tue, Jun 23, 2015 at 9:37 PM, Stephen Rothwell  wrote:
> Hi Rusty,
>
> After merging the modules tree, today's linux-next build (x86_64
> allmodconfig) failed like this:

that's weird.  Are you sure it failed during allmodconfig?  I can see
why it would fail like that if CONFIG_MODULES ins't defined, which
I'll send a patch for...

>
> In file included from include/linux/linkage.h:4:0,
>  from include/linux/kernel.h:6,
>  from kernel/params.c:18:
> kernel/params.c: In function 'param_array':
> kernel/params.c:32:42: error: dereferencing pointer to incomplete type
>  #define KPARAM_MUTEX(mod) ((mod) ? &(mod)->param_lock : _lock)
>   ^
> include/linux/compiler.h:164:42: note: in definition of macro 'unlikely'
>  # define unlikely(x) __builtin_expect(!!(x), 0)
>   ^
> kernel/params.c:462:3: note: in expansion of macro 'BUG_ON'
>BUG_ON(!KPARAM_IS_LOCKED(mod));
>^
> kernel/params.c:33:47: note: in expansion of macro 'KPARAM_MUTEX'
>  #define KPARAM_IS_LOCKED(mod) mutex_is_locked(KPARAM_MUTEX(mod))
>^
> kernel/params.c:462:11: note: in expansion of macro 'KPARAM_IS_LOCKED'
>BUG_ON(!KPARAM_IS_LOCKED(mod));
>^
> kernel/params.c: In function 'param_array_get':
> kernel/params.c:32:42: error: dereferencing pointer to incomplete type
>  #define KPARAM_MUTEX(mod) ((mod) ? &(mod)->param_lock : _lock)
>   ^
> include/linux/compiler.h:164:42: note: in definition of macro 'unlikely'
>  # define unlikely(x) __builtin_expect(!!(x), 0)
>   ^
> kernel/params.c:499:3: note: in expansion of macro 'BUG_ON'
>BUG_ON(!KPARAM_IS_LOCKED(p.mod));
>^
> kernel/params.c:33:47: note: in expansion of macro 'KPARAM_MUTEX'
>  #define KPARAM_IS_LOCKED(mod) mutex_is_locked(KPARAM_MUTEX(mod))
>^
> kernel/params.c:499:11: note: in expansion of macro 'KPARAM_IS_LOCKED'
>BUG_ON(!KPARAM_IS_LOCKED(p.mod));
>^
> In file included from include/linux/notifier.h:13:0,
>  from include/linux/memory_hotplug.h:6,
>  from include/linux/mmzone.h:789,
>  from include/linux/gfp.h:5,
>  from include/linux/kmod.h:22,
>  from include/linux/module.h:13,
>  from kernel/params.c:21:
> kernel/params.c: In function 'kernel_param_lock':
> kernel/params.c:32:42: error: dereferencing pointer to incomplete type
>  #define KPARAM_MUTEX(mod) ((mod) ? &(mod)->param_lock : _lock)
>   ^
> include/linux/mutex.h:146:44: note: in definition of macro 'mutex_lock'
>  #define mutex_lock(lock) mutex_lock_nested(lock, 0)
> ^
> kernel/params.c:621:13: note: in expansion of macro 'KPARAM_MUTEX'
>   mutex_lock(KPARAM_MUTEX(mod));
>  ^
> kernel/params.c: In function 'kernel_param_unlock':
> kernel/params.c:32:42: error: dereferencing pointer to incomplete type
>  #define KPARAM_MUTEX(mod) ((mod) ? &(mod)->param_lock : _lock)
>   ^
> kernel/params.c:626:15: note: in expansion of macro 'KPARAM_MUTEX'
>   mutex_unlock(KPARAM_MUTEX(mod));
>^
>
> Caused by commit b51d23e4e9fe ("module: add per-module param_lock").
>
> I am not exactly sure why this fails to build.  It may be an
> interaction with some other change.
>
> I have used the modules tree from next-20150623 for today.
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Stephen Rothwell]

Hi Dan,

On Wed, 24 Jun 2015 14:18:44 -0400 Dan Streetman ddstr...@ieee.org wrote:

 On Tue, Jun 23, 2015 at 9:37 PM, Stephen Rothwell s...@canb.auug.org.au 
 wrote:
 
  After merging the modules tree, today's linux-next build (x86_64
  allmodconfig) failed like this:
 
 that's weird.  Are you sure it failed during allmodconfig?  I can see
 why it would fail like that if CONFIG_MODULES ins't defined, which
 I'll send a patch for...

Pretty sure - and, in any case, I don't do any CONFIG_MODULES=n builds
between tree merges (only later in the day).  That is why I couldn't
figure out what went wrong.

I will apply your patch today and see if that helps.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgppg89WDaTjH.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the modules tree

[Stephen Rothwell]

Hi Dan,

On Thu, 25 Jun 2015 08:57:06 +1000 Stephen Rothwell s...@canb.auug.org.au 
wrote:

 On Wed, 24 Jun 2015 14:18:44 -0400 Dan Streetman ddstr...@ieee.org wrote:
 
  On Tue, Jun 23, 2015 at 9:37 PM, Stephen Rothwell s...@canb.auug.org.au 
  wrote:
  
   After merging the modules tree, today's linux-next build (x86_64
   allmodconfig) failed like this:
  
  that's weird.  Are you sure it failed during allmodconfig?  I can see
  why it would fail like that if CONFIG_MODULES ins't defined, which
  I'll send a patch for...
 
 Pretty sure - and, in any case, I don't do any CONFIG_MODULES=n builds
 between tree merges (only later in the day).  That is why I couldn't
 figure out what went wrong.
 
 I will apply your patch today and see if that helps.

I built without your patch and it failed again, but applying your patch fixes 
it.

Rusty, you can consider this

Tested-by: Stephen Rothwell s...@canb.auug.org.au

for [PATCH] modules: only use mod-param_lock if CONFIG_MODULES
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpZAvvYXZwgD.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the modules tree

[Dan Streetman]

On Tue, Jun 23, 2015 at 9:37 PM, Stephen Rothwell s...@canb.auug.org.au wrote:
 Hi Rusty,

 After merging the modules tree, today's linux-next build (x86_64
 allmodconfig) failed like this:

that's weird.  Are you sure it failed during allmodconfig?  I can see
why it would fail like that if CONFIG_MODULES ins't defined, which
I'll send a patch for...


 In file included from include/linux/linkage.h:4:0,
  from include/linux/kernel.h:6,
  from kernel/params.c:18:
 kernel/params.c: In function 'param_array':
 kernel/params.c:32:42: error: dereferencing pointer to incomplete type
  #define KPARAM_MUTEX(mod) ((mod) ? (mod)-param_lock : param_lock)
   ^
 include/linux/compiler.h:164:42: note: in definition of macro 'unlikely'
  # define unlikely(x) __builtin_expect(!!(x), 0)
   ^
 kernel/params.c:462:3: note: in expansion of macro 'BUG_ON'
BUG_ON(!KPARAM_IS_LOCKED(mod));
^
 kernel/params.c:33:47: note: in expansion of macro 'KPARAM_MUTEX'
  #define KPARAM_IS_LOCKED(mod) mutex_is_locked(KPARAM_MUTEX(mod))
^
 kernel/params.c:462:11: note: in expansion of macro 'KPARAM_IS_LOCKED'
BUG_ON(!KPARAM_IS_LOCKED(mod));
^
 kernel/params.c: In function 'param_array_get':
 kernel/params.c:32:42: error: dereferencing pointer to incomplete type
  #define KPARAM_MUTEX(mod) ((mod) ? (mod)-param_lock : param_lock)
   ^
 include/linux/compiler.h:164:42: note: in definition of macro 'unlikely'
  # define unlikely(x) __builtin_expect(!!(x), 0)
   ^
 kernel/params.c:499:3: note: in expansion of macro 'BUG_ON'
BUG_ON(!KPARAM_IS_LOCKED(p.mod));
^
 kernel/params.c:33:47: note: in expansion of macro 'KPARAM_MUTEX'
  #define KPARAM_IS_LOCKED(mod) mutex_is_locked(KPARAM_MUTEX(mod))
^
 kernel/params.c:499:11: note: in expansion of macro 'KPARAM_IS_LOCKED'
BUG_ON(!KPARAM_IS_LOCKED(p.mod));
^
 In file included from include/linux/notifier.h:13:0,
  from include/linux/memory_hotplug.h:6,
  from include/linux/mmzone.h:789,
  from include/linux/gfp.h:5,
  from include/linux/kmod.h:22,
  from include/linux/module.h:13,
  from kernel/params.c:21:
 kernel/params.c: In function 'kernel_param_lock':
 kernel/params.c:32:42: error: dereferencing pointer to incomplete type
  #define KPARAM_MUTEX(mod) ((mod) ? (mod)-param_lock : param_lock)
   ^
 include/linux/mutex.h:146:44: note: in definition of macro 'mutex_lock'
  #define mutex_lock(lock) mutex_lock_nested(lock, 0)
 ^
 kernel/params.c:621:13: note: in expansion of macro 'KPARAM_MUTEX'
   mutex_lock(KPARAM_MUTEX(mod));
  ^
 kernel/params.c: In function 'kernel_param_unlock':
 kernel/params.c:32:42: error: dereferencing pointer to incomplete type
  #define KPARAM_MUTEX(mod) ((mod) ? (mod)-param_lock : param_lock)
   ^
 kernel/params.c:626:15: note: in expansion of macro 'KPARAM_MUTEX'
   mutex_unlock(KPARAM_MUTEX(mod));
^

 Caused by commit b51d23e4e9fe (module: add per-module param_lock).

 I am not exactly sure why this fails to build.  It may be an
 interaction with some other change.

 I have used the modules tree from next-20150623 for today.

 --
 Cheers,
 Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Stephen Rothwell]

Hi Rusty,

On Thu, 07 Aug 2014 22:37:50 +0930 Rusty Russell  wrote:
>
> Stephen Rothwell  writes:
> > Hi Rusty,
> >
> > On Thu, 07 Aug 2014 21:07:20 +0930 Rusty Russell  
> > wrote:
> >>
> >> Ah, crap.  I really hate that macro magic :(
> >> 
> >> I amended to the minimal fix, so we can pretend that never happened.
> >
> > How about arch/powerpc/platforms/powernv/opal-dump.c as well?
> 
> Hmm, I didn't see that one.

It was in the original report, but I guess a bit hidden by all the guff
the gcc spews out these days.

> I've done that as a separate patch.

Thanks.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: linux-next: build failure after merge of the modules tree

[Rusty Russell]

Stephen Rothwell  writes:
> Hi Rusty,
>
> On Thu, 07 Aug 2014 21:07:20 +0930 Rusty Russell  
> wrote:
>>
>> Ah, crap.  I really hate that macro magic :(
>> 
>> I amended to the minimal fix, so we can pretend that never happened.
>
> How about arch/powerpc/platforms/powernv/opal-dump.c as well?

Hmm, I didn't see that one.

I've done that as a separate patch.

Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Stephen Rothwell]

Hi Rusty,

On Thu, 07 Aug 2014 21:07:20 +0930 Rusty Russell  wrote:
>
> Ah, crap.  I really hate that macro magic :(
> 
> I amended to the minimal fix, so we can pretend that never happened.

How about arch/powerpc/platforms/powernv/opal-dump.c as well?

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: linux-next: build failure after merge of the modules tree

[Rusty Russell]

Stephen Rothwell  writes:
> Hi Rusty,
>
> After merging the modules tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> arch/powerpc/platforms/powernv/opal-elog.c:85:28: error: macro "__ATTR_RO" 
> passed 2 arguments, but takes just 1
>   __ATTR_RO(id, elog_id_show);

Ah, crap.  I really hate that macro magic :(

I amended to the minimal fix, so we can pretend that never happened.

Cheers,
Rusty.

commit 6656c21ca10e54a84673d0ec2f0cf5f676e66a40
Author: Rusty Russell 
Date:   Wed Aug 6 10:15:36 2014 +0930

arch/powerpc/platforms/powernv/opal-elog.c: fix world-writable sysfs files

If you don't have a store function, you're not writable anyway!

Signed-off-by: Rusty Russell 
Acked-by: Stewart Smith 

diff --git a/arch/powerpc/platforms/powernv/opal-elog.c 
b/arch/powerpc/platforms/powernv/opal-elog.c
index 10268c41d830..925bad993e30 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -82,9 +82,9 @@ static ssize_t elog_ack_store(struct elog_obj *elog_obj,
 }
 
 static struct elog_attribute id_attribute =
-   __ATTR(id, 0666, elog_id_show, NULL);
+   __ATTR(id, S_IRUGO, elog_id_show, NULL);
 static struct elog_attribute type_attribute =
-   __ATTR(type, 0666, elog_type_show, NULL);
+   __ATTR(type, S_IRUGO, elog_type_show, NULL);
 static struct elog_attribute ack_attribute =
__ATTR(acknowledge, 0660, elog_ack_show, elog_ack_store);
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Rusty Russell]

Stephen Rothwell s...@canb.auug.org.au writes:
 Hi Rusty,

 After merging the modules tree, today's linux-next build (powerpc
 ppc64_defconfig) failed like this:

 arch/powerpc/platforms/powernv/opal-elog.c:85:28: error: macro __ATTR_RO 
 passed 2 arguments, but takes just 1
   __ATTR_RO(id, elog_id_show);

Ah, crap.  I really hate that macro magic :(

I amended to the minimal fix, so we can pretend that never happened.

Cheers,
Rusty.

commit 6656c21ca10e54a84673d0ec2f0cf5f676e66a40
Author: Rusty Russell ru...@rustcorp.com.au
Date:   Wed Aug 6 10:15:36 2014 +0930

arch/powerpc/platforms/powernv/opal-elog.c: fix world-writable sysfs files

If you don't have a store function, you're not writable anyway!

Signed-off-by: Rusty Russell ru...@rustcorp.com.au
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com

diff --git a/arch/powerpc/platforms/powernv/opal-elog.c 
b/arch/powerpc/platforms/powernv/opal-elog.c
index 10268c41d830..925bad993e30 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -82,9 +82,9 @@ static ssize_t elog_ack_store(struct elog_obj *elog_obj,
 }
 
 static struct elog_attribute id_attribute =
-   __ATTR(id, 0666, elog_id_show, NULL);
+   __ATTR(id, S_IRUGO, elog_id_show, NULL);
 static struct elog_attribute type_attribute =
-   __ATTR(type, 0666, elog_type_show, NULL);
+   __ATTR(type, S_IRUGO, elog_type_show, NULL);
 static struct elog_attribute ack_attribute =
__ATTR(acknowledge, 0660, elog_ack_show, elog_ack_store);
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Stephen Rothwell]

Hi Rusty,

On Thu, 07 Aug 2014 21:07:20 +0930 Rusty Russell ru...@rustcorp.com.au wrote:

 Ah, crap.  I really hate that macro magic :(
 
 I amended to the minimal fix, so we can pretend that never happened.

How about arch/powerpc/platforms/powernv/opal-dump.c as well?

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: linux-next: build failure after merge of the modules tree

[Rusty Russell]

Stephen Rothwell s...@canb.auug.org.au writes:
 Hi Rusty,

 On Thu, 07 Aug 2014 21:07:20 +0930 Rusty Russell ru...@rustcorp.com.au 
 wrote:

 Ah, crap.  I really hate that macro magic :(
 
 I amended to the minimal fix, so we can pretend that never happened.

 How about arch/powerpc/platforms/powernv/opal-dump.c as well?

Hmm, I didn't see that one.

I've done that as a separate patch.

Thanks,
Rusty.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Stephen Rothwell]

Hi Rusty,

On Thu, 07 Aug 2014 22:37:50 +0930 Rusty Russell ru...@rustcorp.com.au wrote:

 Stephen Rothwell s...@canb.auug.org.au writes:
  Hi Rusty,
 
  On Thu, 07 Aug 2014 21:07:20 +0930 Rusty Russell ru...@rustcorp.com.au 
  wrote:
 
  Ah, crap.  I really hate that macro magic :(
  
  I amended to the minimal fix, so we can pretend that never happened.
 
  How about arch/powerpc/platforms/powernv/opal-dump.c as well?
 
 Hmm, I didn't see that one.

It was in the original report, but I guess a bit hidden by all the guff
the gcc spews out these days.

 I've done that as a separate patch.

Thanks.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: linux-next: build failure after merge of the modules tree

[Rusty Russell]

Stephen Rothwell  writes:
> Hi Rusty,
>
> After merging the modules tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:

Thanks, I've sent off a fix for that file, and asked Stewart for an
Ack:

Subject: arch/powerpc/platforms/powernv/opal-elog.c: fix world-writable sysfs 
files

If you don't have a store function, you're not writable anyway!

Signed-off-by: Rusty Russell 

diff --git a/arch/powerpc/platforms/powernv/opal-elog.c 
b/arch/powerpc/platforms/powernv/opal-elog.c
index 10268c41d830..d59dc2a60260 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -82,9 +82,9 @@ static ssize_t elog_ack_store(struct elog_obj *elog_obj,
 }
 
 static struct elog_attribute id_attribute =
-   __ATTR(id, 0666, elog_id_show, NULL);
+   __ATTR_RO(id, elog_id_show);
 static struct elog_attribute type_attribute =
-   __ATTR(type, 0666, elog_type_show, NULL);
+   __ATTR_RO(type, elog_type_show);
 static struct elog_attribute ack_attribute =
__ATTR(acknowledge, 0660, elog_ack_show, elog_ack_store);
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Rusty Russell]

Stephen Rothwell s...@canb.auug.org.au writes:
 Hi Rusty,

 After merging the modules tree, today's linux-next build (powerpc
 ppc64_defconfig) failed like this:

Thanks, I've sent off a fix for that file, and asked Stewart for an
Ack:

Subject: arch/powerpc/platforms/powernv/opal-elog.c: fix world-writable sysfs 
files

If you don't have a store function, you're not writable anyway!

Signed-off-by: Rusty Russell ru...@rustcorp.com.au

diff --git a/arch/powerpc/platforms/powernv/opal-elog.c 
b/arch/powerpc/platforms/powernv/opal-elog.c
index 10268c41d830..d59dc2a60260 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -82,9 +82,9 @@ static ssize_t elog_ack_store(struct elog_obj *elog_obj,
 }
 
 static struct elog_attribute id_attribute =
-   __ATTR(id, 0666, elog_id_show, NULL);
+   __ATTR_RO(id, elog_id_show);
 static struct elog_attribute type_attribute =
-   __ATTR(type, 0666, elog_type_show, NULL);
+   __ATTR_RO(type, elog_type_show);
 static struct elog_attribute ack_attribute =
__ATTR(acknowledge, 0660, elog_ack_show, elog_ack_store);
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Rusty Russell]

Stephen Rothwell  writes:
> Hi Rusty,
>
> After merging the modules tree, today's linux-next build (x86_64
> allmodconfig) failed like this:

Hmm, I sent Greg KH a separate patch for staging, which rips these out
altogether.  He said he'd apply it "in a bit".

I see it hasn't hit mainline yet, so here it is.

From: Rusty Russell 
Subject: staging: fix up speakup kobject mode

It uses the unnecessary S_IFREG bit which will break when my
stricter-checking-for-mode patch goes in.

Since we're fixing it anyway, the extra level of indirection is
confusing for readers (ROOT_W == rw-r--r-- for example).

Also, many of these are other-writable.  Is that really intended?

Signed-off-by: Rusty Russell 
---
 drivers/staging/speakup/kobjects.c   | 62 
 drivers/staging/speakup/speakup.h|  2 --
 drivers/staging/speakup/speakup_acntpc.c | 22 ++--
 drivers/staging/speakup/speakup_acntsa.c | 22 ++--
 drivers/staging/speakup/speakup_apollo.c | 24 ++---
 drivers/staging/speakup/speakup_audptr.c | 24 ++---
 drivers/staging/speakup/speakup_bns.c| 22 ++--
 drivers/staging/speakup/speakup_decext.c | 24 ++---
 drivers/staging/speakup/speakup_decpc.c  | 24 ++---
 drivers/staging/speakup/speakup_dectlk.c | 24 ++---
 drivers/staging/speakup/speakup_dtlk.c   | 28 +++
 drivers/staging/speakup/speakup_dummy.c  | 22 ++--
 drivers/staging/speakup/speakup_keypc.c  | 18 +-
 drivers/staging/speakup/speakup_ltlk.c   | 28 +++
 drivers/staging/speakup/speakup_soft.c   | 30 
 drivers/staging/speakup/speakup_spkout.c | 24 ++---
 drivers/staging/speakup/speakup_txprt.c  | 22 ++--
 17 files changed, 210 insertions(+), 212 deletions(-)

diff --git a/drivers/staging/speakup/kobjects.c 
b/drivers/staging/speakup/kobjects.c
index e2f597ee6261..1ca91f7092b1 100644
--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -851,75 +851,75 @@ static ssize_t message_store(struct kobject *kobj, struct 
kobj_attribute *attr,
  * Declare the attributes.
  */
 static struct kobj_attribute keymap_attribute =
-   __ATTR(keymap, ROOT_W, keymap_show, keymap_store);
+   __ATTR(keymap, S_IWUSR|S_IRUGO, keymap_show, keymap_store);
 static struct kobj_attribute silent_attribute =
-   __ATTR(silent, USER_W, NULL, silent_store);
+   __ATTR(silent, S_IWUGO, NULL, silent_store);
 static struct kobj_attribute synth_attribute =
-   __ATTR(synth, USER_RW, synth_show, synth_store);
+   __ATTR(synth, S_IWUGO|S_IRUGO, synth_show, synth_store);
 static struct kobj_attribute synth_direct_attribute =
-   __ATTR(synth_direct, USER_W, NULL, synth_direct_store);
+   __ATTR(synth_direct, S_IWUGO, NULL, synth_direct_store);
 static struct kobj_attribute version_attribute =
__ATTR_RO(version);
 
 static struct kobj_attribute delimiters_attribute =
-   __ATTR(delimiters, USER_RW, punc_show, punc_store);
+   __ATTR(delimiters, S_IWUGO|S_IRUGO, punc_show, punc_store);
 static struct kobj_attribute ex_num_attribute =
-   __ATTR(ex_num, USER_RW, punc_show, punc_store);
+   __ATTR(ex_num, S_IWUGO|S_IRUGO, punc_show, punc_store);
 static struct kobj_attribute punc_all_attribute =
-   __ATTR(punc_all, USER_RW, punc_show, punc_store);
+   __ATTR(punc_all, S_IWUGO|S_IRUGO, punc_show, punc_store);
 static struct kobj_attribute punc_most_attribute =
-   __ATTR(punc_most, USER_RW, punc_show, punc_store);
+   __ATTR(punc_most, S_IWUGO|S_IRUGO, punc_show, punc_store);
 static struct kobj_attribute punc_some_attribute =
-   __ATTR(punc_some, USER_RW, punc_show, punc_store);
+   __ATTR(punc_some, S_IWUGO|S_IRUGO, punc_show, punc_store);
 static struct kobj_attribute repeats_attribute =
-   __ATTR(repeats, USER_RW, punc_show, punc_store);
+   __ATTR(repeats, S_IWUGO|S_IRUGO, punc_show, punc_store);
 
 static struct kobj_attribute attrib_bleep_attribute =
-   __ATTR(attrib_bleep, USER_RW, spk_var_show, spk_var_store);
+   __ATTR(attrib_bleep, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store);
 static struct kobj_attribute bell_pos_attribute =
-   __ATTR(bell_pos, USER_RW, spk_var_show, spk_var_store);
+   __ATTR(bell_pos, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store);
 static struct kobj_attribute bleep_time_attribute =
-   __ATTR(bleep_time, USER_RW, spk_var_show, spk_var_store);
+   __ATTR(bleep_time, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store);
 static struct kobj_attribute bleeps_attribute =
-   __ATTR(bleeps, USER_RW, spk_var_show, spk_var_store);
+   __ATTR(bleeps, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store);
 static struct kobj_attribute cursor_time_attribute =
-   __ATTR(cursor_time, USER_RW, spk_var_show, spk_var_store);
+   __ATTR(cursor_time, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store);
 static struct kobj_attribute key_echo_attribute =
-   

Re: linux-next: build failure after merge of the modules tree

[Rusty Russell]

Stephen Rothwell s...@canb.auug.org.au writes:
 Hi Rusty,

 After merging the modules tree, today's linux-next build (x86_64
 allmodconfig) failed like this:

Hmm, I sent Greg KH a separate patch for staging, which rips these out
altogether.  He said he'd apply it in a bit.

I see it hasn't hit mainline yet, so here it is.

From: Rusty Russell ru...@rustcorp.com.au
Subject: staging: fix up speakup kobject mode

It uses the unnecessary S_IFREG bit which will break when my
stricter-checking-for-mode patch goes in.

Since we're fixing it anyway, the extra level of indirection is
confusing for readers (ROOT_W == rw-r--r-- for example).

Also, many of these are other-writable.  Is that really intended?

Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
 drivers/staging/speakup/kobjects.c   | 62 
 drivers/staging/speakup/speakup.h|  2 --
 drivers/staging/speakup/speakup_acntpc.c | 22 ++--
 drivers/staging/speakup/speakup_acntsa.c | 22 ++--
 drivers/staging/speakup/speakup_apollo.c | 24 ++---
 drivers/staging/speakup/speakup_audptr.c | 24 ++---
 drivers/staging/speakup/speakup_bns.c| 22 ++--
 drivers/staging/speakup/speakup_decext.c | 24 ++---
 drivers/staging/speakup/speakup_decpc.c  | 24 ++---
 drivers/staging/speakup/speakup_dectlk.c | 24 ++---
 drivers/staging/speakup/speakup_dtlk.c   | 28 +++
 drivers/staging/speakup/speakup_dummy.c  | 22 ++--
 drivers/staging/speakup/speakup_keypc.c  | 18 +-
 drivers/staging/speakup/speakup_ltlk.c   | 28 +++
 drivers/staging/speakup/speakup_soft.c   | 30 
 drivers/staging/speakup/speakup_spkout.c | 24 ++---
 drivers/staging/speakup/speakup_txprt.c  | 22 ++--
 17 files changed, 210 insertions(+), 212 deletions(-)

diff --git a/drivers/staging/speakup/kobjects.c 
b/drivers/staging/speakup/kobjects.c
index e2f597ee6261..1ca91f7092b1 100644
--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -851,75 +851,75 @@ static ssize_t message_store(struct kobject *kobj, struct 
kobj_attribute *attr,
  * Declare the attributes.
  */
 static struct kobj_attribute keymap_attribute =
-   __ATTR(keymap, ROOT_W, keymap_show, keymap_store);
+   __ATTR(keymap, S_IWUSR|S_IRUGO, keymap_show, keymap_store);
 static struct kobj_attribute silent_attribute =
-   __ATTR(silent, USER_W, NULL, silent_store);
+   __ATTR(silent, S_IWUGO, NULL, silent_store);
 static struct kobj_attribute synth_attribute =
-   __ATTR(synth, USER_RW, synth_show, synth_store);
+   __ATTR(synth, S_IWUGO|S_IRUGO, synth_show, synth_store);
 static struct kobj_attribute synth_direct_attribute =
-   __ATTR(synth_direct, USER_W, NULL, synth_direct_store);
+   __ATTR(synth_direct, S_IWUGO, NULL, synth_direct_store);
 static struct kobj_attribute version_attribute =
__ATTR_RO(version);
 
 static struct kobj_attribute delimiters_attribute =
-   __ATTR(delimiters, USER_RW, punc_show, punc_store);
+   __ATTR(delimiters, S_IWUGO|S_IRUGO, punc_show, punc_store);
 static struct kobj_attribute ex_num_attribute =
-   __ATTR(ex_num, USER_RW, punc_show, punc_store);
+   __ATTR(ex_num, S_IWUGO|S_IRUGO, punc_show, punc_store);
 static struct kobj_attribute punc_all_attribute =
-   __ATTR(punc_all, USER_RW, punc_show, punc_store);
+   __ATTR(punc_all, S_IWUGO|S_IRUGO, punc_show, punc_store);
 static struct kobj_attribute punc_most_attribute =
-   __ATTR(punc_most, USER_RW, punc_show, punc_store);
+   __ATTR(punc_most, S_IWUGO|S_IRUGO, punc_show, punc_store);
 static struct kobj_attribute punc_some_attribute =
-   __ATTR(punc_some, USER_RW, punc_show, punc_store);
+   __ATTR(punc_some, S_IWUGO|S_IRUGO, punc_show, punc_store);
 static struct kobj_attribute repeats_attribute =
-   __ATTR(repeats, USER_RW, punc_show, punc_store);
+   __ATTR(repeats, S_IWUGO|S_IRUGO, punc_show, punc_store);
 
 static struct kobj_attribute attrib_bleep_attribute =
-   __ATTR(attrib_bleep, USER_RW, spk_var_show, spk_var_store);
+   __ATTR(attrib_bleep, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store);
 static struct kobj_attribute bell_pos_attribute =
-   __ATTR(bell_pos, USER_RW, spk_var_show, spk_var_store);
+   __ATTR(bell_pos, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store);
 static struct kobj_attribute bleep_time_attribute =
-   __ATTR(bleep_time, USER_RW, spk_var_show, spk_var_store);
+   __ATTR(bleep_time, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store);
 static struct kobj_attribute bleeps_attribute =
-   __ATTR(bleeps, USER_RW, spk_var_show, spk_var_store);
+   __ATTR(bleeps, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store);
 static struct kobj_attribute cursor_time_attribute =
-   __ATTR(cursor_time, USER_RW, spk_var_show, spk_var_store);
+   __ATTR(cursor_time, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store);
 static struct 

Re: linux-next: build failure after merge of the modules tree

[Rusty Russell]

Stanislaw Gruszka  writes:

> On Mon, Nov 26, 2012 at 03:10:46PM +1100, Stephen Rothwell wrote:
>> After merging the modules tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>> 
>> drivers/net/wireless/iwlwifi/iwl-drv.c:1196:1: error: invalid suffix 
>> "n_disabletype__8" on integer constant
>> drivers/net/wireless/iwlwifi/iwl-drv.c:1196:1: error: expected identifier or 
>> '(' before numeric constant
>> drivers/net/wireless/iwlwifi/iwl-drv.c:1198:1: error: invalid suffix 
>> "n_disable__9" on integer constant
>> drivers/net/wireless/iwlwifi/iwl-drv.c:1198:1: error: expected identifier or 
>> '(' before numeric constant
>> drivers/net/wireless/iwlwifi/iwl-drv.c:1263:1: error: invalid suffix 
>> "ghz_disabletype__32" on integer constant
>> drivers/net/wireless/iwlwifi/iwl-drv.c:1263:1: error: expected identifier or 
>> '(' before numeric constant
>> drivers/net/wireless/iwlwifi/iwl-drv.c:1264:1: error: invalid suffix 
>> "ghz_disable__33" on integer constant
>> drivers/net/wireless/iwlwifi/iwl-drv.c:1264:1: error: expected identifier or 
>> '(' before numeric constant
>> drivers/net/wireless/iwlegacy/4965-mac.c:6825:1: error: invalid suffix 
>> "n_disabletype__11" on integer constant
>> drivers/net/wireless/iwlegacy/4965-mac.c:6825:1: error: expected identifier 
>> or '(' before numeric constant
>> drivers/net/wireless/iwlegacy/4965-mac.c:6826:1: error: invalid suffix 
>> "n_disable__12" on integer constant
>> drivers/net/wireless/iwlegacy/4965-mac.c:6826:1: error: expected identifier 
>> or '(' before numeric constant
>> 
>> Presumably caused by commit 58876af0436e ("moduleparam: use __UNIQUE_ID
>> ()").  This commit removed the "__mod_" prefix that used to be added to
>> the front of the "name" passed to module_param_named().  Admittedly, the
>> documentation says that "name" must be "a valid C identifier which is the
>> parameter name", but the (ab)usage here used to work (the name starts
>> with a number).
>
> I prefer not to change module parameters name, since there are users
> who use current name in they modprobe config.
>
> Stanislaw

Yes, the names can't be changed.

Here's the patch I've applied, which fixes it:

>From 7a918c7fb6499179e14a4e23a5ccff0ab920ffe0 Mon Sep 17 00:00:00 2001
From: Rusty Russell 
Date: Mon, 3 Dec 2012 10:49:29 +1030
Subject: [PATCH] compiler: fix UNIQUE_ID() for non-identifier names.

Some modules have parameters starting with digits, so always prepend UNIQUE_ID_
which ensures we produce a valid identifier, plus leave a clue if you
should encounter such a symbol.

Reported-by: Stephen Rothwell 
Cc: Stanislaw Gruszka 
Signed-off-by: Rusty Russell 
---
 include/linux/compiler-gcc4.h |2 +-
 include/linux/compiler.h  |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 8908821..56c802c 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -31,7 +31,7 @@
 
 #define __linktime_error(message) __attribute__((__error__(message)))
 
-#define __UNIQUE_ID(prefix) __PASTE(prefix, __PASTE(__, __COUNTER__))
+#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
 
 #if __GNUC_MINOR__ >= 5
 /*
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index c55ae87..5f45335 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -170,7 +170,7 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int 
val, int expect);
 
 /* Not-quite-unique ID. */
 #ifndef __UNIQUE_ID
-# define __UNIQUE_ID(prefix) __PASTE(__PASTE(prefix, __), __LINE__)
+# define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __LINE__)
 #endif
 
 #endif /* __KERNEL__ */
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Rusty Russell]

Stanislaw Gruszka sgrus...@redhat.com writes:

 On Mon, Nov 26, 2012 at 03:10:46PM +1100, Stephen Rothwell wrote:
 After merging the modules tree, today's linux-next build (x86_64
 allmodconfig) failed like this:
 
 drivers/net/wireless/iwlwifi/iwl-drv.c:1196:1: error: invalid suffix 
 n_disabletype__8 on integer constant
 drivers/net/wireless/iwlwifi/iwl-drv.c:1196:1: error: expected identifier or 
 '(' before numeric constant
 drivers/net/wireless/iwlwifi/iwl-drv.c:1198:1: error: invalid suffix 
 n_disable__9 on integer constant
 drivers/net/wireless/iwlwifi/iwl-drv.c:1198:1: error: expected identifier or 
 '(' before numeric constant
 drivers/net/wireless/iwlwifi/iwl-drv.c:1263:1: error: invalid suffix 
 ghz_disabletype__32 on integer constant
 drivers/net/wireless/iwlwifi/iwl-drv.c:1263:1: error: expected identifier or 
 '(' before numeric constant
 drivers/net/wireless/iwlwifi/iwl-drv.c:1264:1: error: invalid suffix 
 ghz_disable__33 on integer constant
 drivers/net/wireless/iwlwifi/iwl-drv.c:1264:1: error: expected identifier or 
 '(' before numeric constant
 drivers/net/wireless/iwlegacy/4965-mac.c:6825:1: error: invalid suffix 
 n_disabletype__11 on integer constant
 drivers/net/wireless/iwlegacy/4965-mac.c:6825:1: error: expected identifier 
 or '(' before numeric constant
 drivers/net/wireless/iwlegacy/4965-mac.c:6826:1: error: invalid suffix 
 n_disable__12 on integer constant
 drivers/net/wireless/iwlegacy/4965-mac.c:6826:1: error: expected identifier 
 or '(' before numeric constant
 
 Presumably caused by commit 58876af0436e (moduleparam: use __UNIQUE_ID
 ()).  This commit removed the __mod_ prefix that used to be added to
 the front of the name passed to module_param_named().  Admittedly, the
 documentation says that name must be a valid C identifier which is the
 parameter name, but the (ab)usage here used to work (the name starts
 with a number).

 I prefer not to change module parameters name, since there are users
 who use current name in they modprobe config.

 Stanislaw

Yes, the names can't be changed.

Here's the patch I've applied, which fixes it:

From 7a918c7fb6499179e14a4e23a5ccff0ab920ffe0 Mon Sep 17 00:00:00 2001
From: Rusty Russell ru...@rustcorp.com.au
Date: Mon, 3 Dec 2012 10:49:29 +1030
Subject: [PATCH] compiler: fix UNIQUE_ID() for non-identifier names.

Some modules have parameters starting with digits, so always prepend UNIQUE_ID_
which ensures we produce a valid identifier, plus leave a clue if you
should encounter such a symbol.

Reported-by: Stephen Rothwell s...@canb.auug.org.au
Cc: Stanislaw Gruszka sgrus...@redhat.com
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
 include/linux/compiler-gcc4.h |2 +-
 include/linux/compiler.h  |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 8908821..56c802c 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -31,7 +31,7 @@
 
 #define __linktime_error(message) __attribute__((__error__(message)))
 
-#define __UNIQUE_ID(prefix) __PASTE(prefix, __PASTE(__, __COUNTER__))
+#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
 
 #if __GNUC_MINOR__ = 5
 /*
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index c55ae87..5f45335 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -170,7 +170,7 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int 
val, int expect);
 
 /* Not-quite-unique ID. */
 #ifndef __UNIQUE_ID
-# define __UNIQUE_ID(prefix) __PASTE(__PASTE(prefix, __), __LINE__)
+# define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __LINE__)
 #endif
 
 #endif /* __KERNEL__ */
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Stanislaw Gruszka]

On Mon, Nov 26, 2012 at 03:10:46PM +1100, Stephen Rothwell wrote:
> After merging the modules tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/net/wireless/iwlwifi/iwl-drv.c:1196:1: error: invalid suffix 
> "n_disabletype__8" on integer constant
> drivers/net/wireless/iwlwifi/iwl-drv.c:1196:1: error: expected identifier or 
> '(' before numeric constant
> drivers/net/wireless/iwlwifi/iwl-drv.c:1198:1: error: invalid suffix 
> "n_disable__9" on integer constant
> drivers/net/wireless/iwlwifi/iwl-drv.c:1198:1: error: expected identifier or 
> '(' before numeric constant
> drivers/net/wireless/iwlwifi/iwl-drv.c:1263:1: error: invalid suffix 
> "ghz_disabletype__32" on integer constant
> drivers/net/wireless/iwlwifi/iwl-drv.c:1263:1: error: expected identifier or 
> '(' before numeric constant
> drivers/net/wireless/iwlwifi/iwl-drv.c:1264:1: error: invalid suffix 
> "ghz_disable__33" on integer constant
> drivers/net/wireless/iwlwifi/iwl-drv.c:1264:1: error: expected identifier or 
> '(' before numeric constant
> drivers/net/wireless/iwlegacy/4965-mac.c:6825:1: error: invalid suffix 
> "n_disabletype__11" on integer constant
> drivers/net/wireless/iwlegacy/4965-mac.c:6825:1: error: expected identifier 
> or '(' before numeric constant
> drivers/net/wireless/iwlegacy/4965-mac.c:6826:1: error: invalid suffix 
> "n_disable__12" on integer constant
> drivers/net/wireless/iwlegacy/4965-mac.c:6826:1: error: expected identifier 
> or '(' before numeric constant
> 
> Presumably caused by commit 58876af0436e ("moduleparam: use __UNIQUE_ID
> ()").  This commit removed the "__mod_" prefix that used to be added to
> the front of the "name" passed to module_param_named().  Admittedly, the
> documentation says that "name" must be "a valid C identifier which is the
> parameter name", but the (ab)usage here used to work (the name starts
> with a number).

I prefer not to change module parameters name, since there are users
who use current name in they modprobe config.

Stanislaw

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Stanislaw Gruszka]

On Mon, Nov 26, 2012 at 03:10:46PM +1100, Stephen Rothwell wrote:
 After merging the modules tree, today's linux-next build (x86_64
 allmodconfig) failed like this:
 
 drivers/net/wireless/iwlwifi/iwl-drv.c:1196:1: error: invalid suffix 
 n_disabletype__8 on integer constant
 drivers/net/wireless/iwlwifi/iwl-drv.c:1196:1: error: expected identifier or 
 '(' before numeric constant
 drivers/net/wireless/iwlwifi/iwl-drv.c:1198:1: error: invalid suffix 
 n_disable__9 on integer constant
 drivers/net/wireless/iwlwifi/iwl-drv.c:1198:1: error: expected identifier or 
 '(' before numeric constant
 drivers/net/wireless/iwlwifi/iwl-drv.c:1263:1: error: invalid suffix 
 ghz_disabletype__32 on integer constant
 drivers/net/wireless/iwlwifi/iwl-drv.c:1263:1: error: expected identifier or 
 '(' before numeric constant
 drivers/net/wireless/iwlwifi/iwl-drv.c:1264:1: error: invalid suffix 
 ghz_disable__33 on integer constant
 drivers/net/wireless/iwlwifi/iwl-drv.c:1264:1: error: expected identifier or 
 '(' before numeric constant
 drivers/net/wireless/iwlegacy/4965-mac.c:6825:1: error: invalid suffix 
 n_disabletype__11 on integer constant
 drivers/net/wireless/iwlegacy/4965-mac.c:6825:1: error: expected identifier 
 or '(' before numeric constant
 drivers/net/wireless/iwlegacy/4965-mac.c:6826:1: error: invalid suffix 
 n_disable__12 on integer constant
 drivers/net/wireless/iwlegacy/4965-mac.c:6826:1: error: expected identifier 
 or '(' before numeric constant
 
 Presumably caused by commit 58876af0436e (moduleparam: use __UNIQUE_ID
 ()).  This commit removed the __mod_ prefix that used to be added to
 the front of the name passed to module_param_named().  Admittedly, the
 documentation says that name must be a valid C identifier which is the
 parameter name, but the (ab)usage here used to work (the name starts
 with a number).

I prefer not to change module parameters name, since there are users
who use current name in they modprobe config.

Stanislaw

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Rusty Russell]

Stephen Rothwell  writes:
> Hi Rusty,
>
> After merging the modules tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:

As this is in Andrew's tree, I've reverted it from my modules-next tree.

Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the modules tree

[Rusty Russell]

Stephen Rothwell s...@canb.auug.org.au writes:
 Hi Rusty,

 After merging the modules tree, today's linux-next build (powerpc
 ppc64_defconfig) failed like this:

As this is in Andrew's tree, I've reverted it from my modules-next tree.

Thanks,
Rusty.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/