Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1501639 > unrolled thread

Re: [GIT PULL] kbuild changes for v4.9-rc1

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [GIT PULL] kbuild changes for v4.9-rc1 Nicholas Piggin <npiggin@gmail.com> - 2016-10-17 09:10 +0200
    Re: [GIT PULL] kbuild changes for v4.9-rc1 Adam Borowski <kilobyte@angband.pl> - 2016-10-17 12:10 +0200
      Re: [GIT PULL] kbuild changes for v4.9-rc1 Geert Uytterhoeven <geert@linux-m68k.org> - 2016-10-17 13:20 +0200
        Re: [GIT PULL] kbuild changes for v4.9-rc1 Alexey Dobriyan <adobriyan@gmail.com> - 2016-10-17 13:40 +0200
      Re: [GIT PULL] kbuild changes for v4.9-rc1 Alexey Dobriyan <adobriyan@gmail.com> - 2016-10-17 13:20 +0200
      Re: [GIT PULL] kbuild changes for v4.9-rc1 Mathieu OTHACEHE <m.othacehe@gmail.com> - 2016-10-17 14:30 +0200
        Re: [GIT PULL] kbuild changes for v4.9-rc1 Adam Borowski <kilobyte@angband.pl> - 2016-10-18 02:20 +0200
          Re: [GIT PULL] kbuild changes for v4.9-rc1 Nicholas Piggin <npiggin@gmail.com> - 2016-10-18 03:40 +0200
            Re: [GIT PULL] kbuild changes for v4.9-rc1 Michal Marek <mmarek@suse.com> - 2016-10-19 16:40 +0200
              Re: [GIT PULL] kbuild changes for v4.9-rc1 Nicholas Piggin <npiggin@gmail.com> - 2016-10-20 06:00 +0200
                Re: [GIT PULL] kbuild changes for v4.9-rc1 Kalle Valo <kvalo@codeaurora.org> - 2016-10-27 16:00 +0200
                  Re: [GIT PULL] kbuild changes for v4.9-rc1 Nicholas Piggin <npiggin@gmail.com> - 2016-10-27 16:40 +0200
                Re: [GIT PULL] kbuild changes for v4.9-rc1 Kalle Valo <kvalo@codeaurora.org> - 2016-10-27 16:20 +0200
                  Re: [GIT PULL] kbuild changes for v4.9-rc1 Nicholas Piggin <npiggin@gmail.com> - 2016-10-27 17:00 +0200
                  Re: [GIT PULL] kbuild changes for v4.9-rc1 Thorsten Leemhuis <regressions@leemhuis.info> - 2016-10-30 12:00 +0100
            Re: [GIT PULL] kbuild changes for v4.9-rc1 Michal Marek <mmarek@suse.com> - 2016-11-01 16:50 +0100
              Re: [GIT PULL] kbuild changes for v4.9-rc1 Adam Borowski <kilobyte@angband.pl> - 2016-11-02 13:20 +0100
                [PATCH] kbuild: provide include/asm/asm-prototypes.h for x86 Adam Borowski <kilobyte@angband.pl> - 2016-11-02 13:20 +0100
    [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM Arnd Bergmann <arnd@arndb.de> - 2016-10-17 14:30 +0200
      Re: [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM Michal Marek <mmarek@suse.com> - 2016-10-19 17:00 +0200
        Re: [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM Arnd Bergmann <arnd@arndb.de> - 2016-10-19 17:10 +0200
          Re: [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-10-19 17:40 +0200
            Re: [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM Nicholas Piggin <npiggin@gmail.com> - 2016-10-20 06:20 +0200
              Re: [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-10-20 15:30 +0200
                Re: [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM Nicholas Piggin <npiggin@gmail.com> - 2016-10-20 16:30 +0200
                  Re: [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-10-20 16:40 +0200
                    Re: [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM Nicholas Piggin <npiggin@gmail.com> - 2016-10-20 17:00 +0200
                    Re: [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM Michal Marek <mmarek@suse.com> - 2016-10-22 22:00 +0200
              [PATCH 2/2, variant A] ARM: add hidden mmioset/mmiocpy prototypes Arnd Bergmann <arnd@arndb.de> - 2016-10-24 17:10 +0200
              [PATCH 2/2, variant B] ARM: move mmiocpy/mmioset exports to io.c Arnd Bergmann <arnd@arndb.de> - 2016-10-24 17:10 +0200
              [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for ARM Arnd Bergmann <arnd@arndb.de> - 2016-10-24 17:10 +0200
                Re: [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for  ARM Nicholas Piggin <npiggin@gmail.com> - 2016-10-25 10:40 +0200
              Re: [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM Arnd Bergmann <arnd@arndb.de> - 2016-10-24 17:10 +0200
            Re: [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM Geert Uytterhoeven <geert@linux-m68k.org> - 2016-10-20 09:40 +0200
              Re: [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-10-20 10:30 +0200
                Re: [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM Geert Uytterhoeven <geert@linux-m68k.org> - 2016-10-20 10:30 +0200

Page 1 of 2  [1] 2  Next page →

#1501639 — Re: [GIT PULL] kbuild changes for v4.9-rc1

On Mon, 17 Oct 2016 08:51:31 +0200
Adam Borowski <kilobyte@angband.pl> wrote:

> On Mon, Oct 17, 2016 at 02:57:09PM +1100, Nicholas Piggin wrote:
> > On Sat, 15 Oct 2016 17:22:05 -0700 Omar Sandoval <osandov@osandov.com> wrote:  
> > > On Fri, Oct 14, 2016 at 10:12:46PM +0200, Michal Marek wrote:  
> > > > please pull these kbuild changes for v4.9-rc1:
> > > > 
> > > > - EXPORT_SYMBOL for asm source by Al Viro. This does bring a regression,
> > > >   because genksyms no longer generates checksums for these symbols
> > > >   (CONFIG_MODVERSIONS). Nick Piggin is working on a patch to fix this.
> > > >   Plus, we are talking about functions like strcpy(), which rarely
> > > >   change prototypes.    
> > > 
> > > So this has broken all module loading for me. I get the following dmesg
> > > spew:
> > > ...
> > > [    4.586914] scsi_mod: no symbol version for memset
> > > [    4.587920] scsi_mod: Unknown symbol memset (err -22)
> > > [    4.588443] scsi_mod: no symbol version for ___preempt_schedule
> > > [    4.589026] scsi_mod: Unknown symbol ___preempt_schedule (err -22)
> > > ...
> > > 
> > > Reverting 784d5699eddc ("x86: move exports to actual definitions") fixes
> > > it for me. This is with GCC 6.2.1, binutils 2.27, attached config.  
> > 
> > Thanks for the report. Could you try this patch and see if it helps?  
> [patch snipped]
> 
> Omar probably won't wake up in quite a while, so I've tested the patch.
> Alas, doesn't help.  Similar spew (for the few modules I don't have =y),
> while reverting 784d5699eddc fixes it for me too.
> 
> Debian sid toolchain: gcc 6.2.0-6, binutils 2.27-8, config at
> https://angband.pl/tmp/config-4.9.0-rc1-debug+.gz

Forgot to engage my brain before posting.

Architectures will need to have an include/asm/asm-prototypes.h that
defines or #include<>s C-style prototypes for exported asm functions.
We can do an asm-generic version for the common ones like memset so
there's not a lot of pointless duplication there.

Care to do a patch for x86?

Thanks,
Nick

[toc] | [next] | [standalone]

#1501840

On Mon, Oct 17, 2016 at 05:59:51PM +1100, Nicholas Piggin wrote:
> On Mon, 17 Oct 2016 08:51:31 +0200
> Adam Borowski <kilobyte@angband.pl> wrote:
> > On Mon, Oct 17, 2016 at 02:57:09PM +1100, Nicholas Piggin wrote:
> > > On Sat, 15 Oct 2016 17:22:05 -0700 Omar Sandoval <osandov@osandov.com> wrote:  
> > > > So this has broken all module loading for me. I get the following dmesg
> > > > spew:
> > > > ...
> > > > [    4.586914] scsi_mod: no symbol version for memset
> > > > [    4.587920] scsi_mod: Unknown symbol memset (err -22)
> > > > [    4.588443] scsi_mod: no symbol version for ___preempt_schedule
> > > > [    4.589026] scsi_mod: Unknown symbol ___preempt_schedule (err -22)
> > > > ...
> > > > 
> > > > Reverting 784d5699eddc ("x86: move exports to actual definitions") fixes
> > > > it for me. This is with GCC 6.2.1, binutils 2.27, attached config.  
> > > 
> > > Thanks for the report. Could you try this patch and see if it helps?  
> > [patch snipped]
> > 
> > Omar probably won't wake up in quite a while, so I've tested the patch.
> > Alas, doesn't help.  Similar spew (for the few modules I don't have =y),
> > while reverting 784d5699eddc fixes it for me too.
> 
> Forgot to engage my brain before posting.
> 
> Architectures will need to have an include/asm/asm-prototypes.h that
> defines or #include<>s C-style prototypes for exported asm functions.
> We can do an asm-generic version for the common ones like memset so
> there's not a lot of pointless duplication there.
> 
> Care to do a patch for x86?

Sure, did so.  With the prototypes added, your patch works!
Tested on a handful of modules, and one out-of-tree (virtualbox).
I didn't try a 32-bit build.

Note that powerpc already has an include/asm/asm-prototypes.h which might or
might not be what you want.  It doesn't have memset and co, for example.

Anyway, here's my stab at x86:


From db746df65b920591606398b4b244f5b6dc9eea04 Mon Sep 17 00:00:00 2001
From: Adam Borowski <kilobyte@angband.pl>
Date: Mon, 17 Oct 2016 11:42:35 +0200
Subject: [PATCH] kbuild: provide include/asm/asm-prototypes.h for x86

Nicholas Piggin wrote:
> Architectures will need to have an include/asm/asm-prototypes.h that
> defines or #include<>s C-style prototypes for exported asm functions.
> We can do an asm-generic version for the common ones like memset so
> there's not a lot of pointless duplication there.

Signed-off-by: Adam Borowski <kilobyte@angband.pl>
---
 arch/x86/include/asm/asm-prototypes.h | 13 +++++++++++++
 include/asm-generic/asm-prototypes.h  |  7 +++++++
 2 files changed, 20 insertions(+)
 create mode 100644 arch/x86/include/asm/asm-prototypes.h
 create mode 100644 include/asm-generic/asm-prototypes.h

diff --git a/arch/x86/include/asm/asm-prototypes.h b/arch/x86/include/asm/asm-prototypes.h
new file mode 100644
index 0000000..072c97c
--- /dev/null
+++ b/arch/x86/include/asm/asm-prototypes.h
@@ -0,0 +1,13 @@
+#include <asm/ftrace.h>
+#include <asm/uaccess.h>
+#include <asm/uaccess.h>
+#include <asm/string.h>
+#include <asm/page.h>
+#include <asm/checksum.h>
+
+#include <asm-generic/asm-prototypes.h>
+
+#include <asm/page.h>
+#include <asm/pgtable.h>
+#include <asm/special_insns.h>
+#include <asm/preempt.h>
diff --git a/include/asm-generic/asm-prototypes.h b/include/asm-generic/asm-prototypes.h
new file mode 100644
index 0000000..df13637
--- /dev/null
+++ b/include/asm-generic/asm-prototypes.h
@@ -0,0 +1,7 @@
+#include <linux/bitops.h>
+extern void *__memset(void *, int, __kernel_size_t);
+extern void *__memcpy(void *, const void *, __kernel_size_t);
+extern void *__memmove(void *, const void *, __kernel_size_t);
+extern void *memset(void *, int, __kernel_size_t);
+extern void *memcpy(void *, const void *, __kernel_size_t);
+extern void *memmove(void *, const void *, __kernel_size_t);
-- 
2.9.3

[toc] | [prev] | [next] | [standalone]

#1501888

Hi Alexey,

On Mon, Oct 17, 2016 at 1:12 PM, Alexey Dobriyan <adobriyan@gmail.com> wrote:
> On Mon, Oct 17, 2016 at 1:01 PM, Adam Borowski <kilobyte@angband.pl> wrote:
>> On Mon, Oct 17, 2016 at 05:59:51PM +1100, Nicholas Piggin wrote:
>>> On Mon, 17 Oct 2016 08:51:31 +0200
>>> Adam Borowski <kilobyte@angband.pl> wrote:
>
>> --- /dev/null
>> +++ b/include/asm-generic/asm-prototypes.h
>> @@ -0,0 +1,7 @@
>> +#include <linux/bitops.h>
>> +extern void *__memset(void *, int, __kernel_size_t);
>> +extern void *__memcpy(void *, const void *, __kernel_size_t);
>> +extern void *__memmove(void *, const void *, __kernel_size_t);
>> +extern void *memset(void *, int, __kernel_size_t);
>> +extern void *memcpy(void *, const void *, __kernel_size_t);
>> +extern void *memmove(void *, const void *, __kernel_size_t);
>
> Before too late, those extern keywords aren't needed and
> only slowdown compilation.

Do you have any profiling data backing this?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1501898

On Mon, Oct 17, 2016 at 2:17 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Alexey,
>
> On Mon, Oct 17, 2016 at 1:12 PM, Alexey Dobriyan <adobriyan@gmail.com> wrote:
>> On Mon, Oct 17, 2016 at 1:01 PM, Adam Borowski <kilobyte@angband.pl> wrote:
>>> On Mon, Oct 17, 2016 at 05:59:51PM +1100, Nicholas Piggin wrote:
>>>> On Mon, 17 Oct 2016 08:51:31 +0200
>>>> Adam Borowski <kilobyte@angband.pl> wrote:
>>
>>> --- /dev/null
>>> +++ b/include/asm-generic/asm-prototypes.h
>>> @@ -0,0 +1,7 @@
>>> +#include <linux/bitops.h>
>>> +extern void *__memset(void *, int, __kernel_size_t);
>>> +extern void *__memcpy(void *, const void *, __kernel_size_t);
>>> +extern void *__memmove(void *, const void *, __kernel_size_t);
>>> +extern void *memset(void *, int, __kernel_size_t);
>>> +extern void *memcpy(void *, const void *, __kernel_size_t);
>>> +extern void *memmove(void *, const void *, __kernel_size_t);
>>
>> Before too late, those extern keywords aren't needed and
>> only slowdown compilation.
>
> Do you have any profiling data backing this?

It is easy to obtain. Here is top 10 with runtime bigger than 0.50%:

_int_malloc
ht_lookup_with_hash
_cpp_lex_direct
cpp_get_token_1
ggc_internal_alloc_statm
_int_free
malloc_consolidate
lex_identifier
enter_macro_context
c_lex_with_flags
bitmap_set_bit
malloc
grokdeclarator
htab_find_slot_with_hash
c_lex_one_token
_cpp_lex_token
pop_scopev
c_parser_declspecs

Imagine you're a compiler. Those extern's are tokens. They need to be parsed
(byte-by-byte), allocated, and, in case of "extern" with prototype, thrown away.
They make line longer forcing people to dance around with splitting
per 80 characters
and generally making everything somewhat slower. Might as well don't new ones.

bitops.h is wrong header as well.
Why do you need bitops for bunch of function prototypes?

[toc] | [prev] | [next] | [standalone]

#1501890

On Mon, Oct 17, 2016 at 1:01 PM, Adam Borowski <kilobyte@angband.pl> wrote:
> On Mon, Oct 17, 2016 at 05:59:51PM +1100, Nicholas Piggin wrote:
>> On Mon, 17 Oct 2016 08:51:31 +0200
>> Adam Borowski <kilobyte@angband.pl> wrote:

> --- /dev/null
> +++ b/include/asm-generic/asm-prototypes.h
> @@ -0,0 +1,7 @@
> +#include <linux/bitops.h>
> +extern void *__memset(void *, int, __kernel_size_t);
> +extern void *__memcpy(void *, const void *, __kernel_size_t);
> +extern void *__memmove(void *, const void *, __kernel_size_t);
> +extern void *memset(void *, int, __kernel_size_t);
> +extern void *memcpy(void *, const void *, __kernel_size_t);
> +extern void *memmove(void *, const void *, __kernel_size_t);

Before too late, those extern keywords aren't needed and
only slowdown compilation.

[toc] | [prev] | [next] | [standalone]

#1501927

> +#include <asm/uaccess.h>
> +#include <asm/uaccess.h>

Included twice.

> +#include <asm/string.h>
> +#include <asm/page.h>
> +#include <asm/checksum.h>
> +
> +#include <asm-generic/asm-prototypes.h>
> +
> +#include <asm/page.h>
> +#include <asm/pgtable.h>
> +#include <asm/special_insns.h>
> +#include <asm/preempt.h>

No <asm/arch_hweight.h> for __sw_hweight32 and __sw_hweight64 ? 

[toc] | [prev] | [next] | [standalone]

#1502602

On Mon, Oct 17, 2016 at 02:22:34PM +0200, Mathieu OTHACEHE wrote:
> > +#include <asm/uaccess.h>
> > +#include <asm/uaccess.h>
> 
> Included twice.

D'oh!

> > +#include <asm/string.h>
> > +#include <asm/page.h>
> > +#include <asm/checksum.h>
> > +
> > +#include <asm-generic/asm-prototypes.h>
> > +
> > +#include <asm/page.h>
> > +#include <asm/pgtable.h>
> > +#include <asm/special_insns.h>
> > +#include <asm/preempt.h>
> 
> No <asm/arch_hweight.h> for __sw_hweight32 and __sw_hweight64 ? 

diff --git a/include/asm-generic/asm-prototypes.h b/include/asm-generic/asm-prototypes.h
new file mode 100644
index 0000000..df13637
--- /dev/null
+++ b/include/asm-generic/asm-prototypes.h
@@ -0,0 +1,7 @@
+#include <linux/bitops.h>

... which has these.

Alexey Dobriyan <adobriyan@gmail.com> wrote:
} bitops.h is wrong header as well.
} Why do you need bitops for bunch of function prototypes?

Unless you guys prefer using low-level headers only, that is.


Meow!
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

[toc] | [prev] | [next] | [standalone]

#1502626

Hi Adam,

Thanks, this is looking good. powerpc will be able to use the generic
header.

On Tue, 18 Oct 2016 02:16:26 +0200
Adam Borowski <kilobyte@angband.pl> wrote:

> On Mon, Oct 17, 2016 at 02:22:34PM +0200, Mathieu OTHACEHE wrote:
> > > +#include <asm/uaccess.h>
> > > +#include <asm/uaccess.h>  
> > 
> > Included twice.  
> 
> D'oh!
> 
> > > +#include <asm/string.h>
> > > +#include <asm/page.h>
> > > +#include <asm/checksum.h>
> > > +
> > > +#include <asm-generic/asm-prototypes.h>
> > > +
> > > +#include <asm/page.h>
> > > +#include <asm/pgtable.h>
> > > +#include <asm/special_insns.h>
> > > +#include <asm/preempt.h>  
> > 
> > No <asm/arch_hweight.h> for __sw_hweight32 and __sw_hweight64 ?   
> 
> diff --git a/include/asm-generic/asm-prototypes.h b/include/asm-generic/asm-prototypes.h
> new file mode 100644
> index 0000000..df13637
> --- /dev/null
> +++ b/include/asm-generic/asm-prototypes.h
> @@ -0,0 +1,7 @@
> +#include <linux/bitops.h>
> 
> ... which has these.
> 
> Alexey Dobriyan <adobriyan@gmail.com> wrote:
> } bitops.h is wrong header as well.
> } Why do you need bitops for bunch of function prototypes?
> 
> Unless you guys prefer using low-level headers only, that is.

Well you can't use asm/arch_hweight.h in a generic header of course.
I would suggest just including linux/ variants where practical for
the asm-generic/asm-prototypes.h header.

We should probably just bring all these arch patches through the
kbuild tree.

I'm sorry for the breakage: I didn't realize it broke the build with
some configs, otherwise I would have given Michal a heads up before
his pull request, and worked to get this stuff in first.

Thanks,
Nick

[toc] | [prev] | [next] | [standalone]

#1503702

Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a):
> We should probably just bring all these arch patches through the
> kbuild tree.
> 
> I'm sorry for the breakage: I didn't realize it broke the build with
> some configs, otherwise I would have given Michal a heads up before
> his pull request, and worked to get this stuff in first.

It breaks with some binutils versions only (and only with
CONFIG_MODVERSIONS=y, of course).

Michal

[toc] | [prev] | [next] | [standalone]

#1504508

On Wed, 19 Oct 2016 16:38:14 +0200
Michal Marek <mmarek@suse.com> wrote:

> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a):
> > We should probably just bring all these arch patches through the
> > kbuild tree.
> > 
> > I'm sorry for the breakage: I didn't realize it broke the build with
> > some configs, otherwise I would have given Michal a heads up before
> > his pull request, and worked to get this stuff in first.  
> 
> It breaks with some binutils versions only (and only with
> CONFIG_MODVERSIONS=y, of course).

Yeah this seems to be the issue, it apparently slipped past all the
automated builds. It seems like the existing CRC warnings in the tree
only trigger in rare circumstances too, so something could be a bit
fragile there.

Thanks,
Nick

[toc] | [prev] | [next] | [standalone]

#1510188

Nicholas Piggin <npiggin@gmail.com> writes:

> On Thu, 27 Oct 2016 11:10:03 +0300
> Kalle Valo <kvalo@codeaurora.org> wrote:
>
>> (Adding Thorsten because of a serious regression and Steven because he
>> tried to fix something in the same commit)
>> 
>> Nicholas Piggin <npiggin@gmail.com> writes:
>> 
>> > On Wed, 19 Oct 2016 16:38:14 +0200
>> > Michal Marek <mmarek@suse.com> wrote:
>> >  
>> >> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a):  
>> >> > We should probably just bring all these arch patches through the
>> >> > kbuild tree.
>> >> > 
>> >> > I'm sorry for the breakage: I didn't realize it broke the build with
>> >> > some configs, otherwise I would have given Michal a heads up before
>> >> > his pull request, and worked to get this stuff in first.    
>> >> 
>> >> It breaks with some binutils versions only (and only with
>> >> CONFIG_MODVERSIONS=y, of course).  
>> >
>> > Yeah this seems to be the issue, it apparently slipped past all the
>> > automated builds. It seems like the existing CRC warnings in the tree
>> > only trigger in rare circumstances too, so something could be a bit
>> > fragile there.  
>> 
>> I upgraded from 4.8 to 4.9-rc2 and noticed that kernel modules fail to
>> load (log below). After investigating for some time I found this thread
>> and apparently this is not still fixed, at least not in Linus' tree.
>> 
>> Reverting 784d5699eddc5 fixed the issue for me. As I don't see any fix
>> available (please correct me if I'm wrong) we should just revert that
>> commit until it's properly fixed.
>
> With these two patches together, does it work for you?
>
> http://marc.info/?l=linux-arch&m=147653546809512&w=2
> http://marc.info/?l=linux-kernel&m=147669851906489&w=2
>
> It would be helpful if you could test and let us know, because there seems
> to be a very tiny number of configs and toolchains that causes
> problems.

With these two patches (on top of ath-201610251249 from ath.git, in
practice 4.9-rc2 + latest wireless patches) module loading works again.
If you want you can add my Tested-by:

Tested-by: Kalle Valo <kvalo@codeaurora.org>

Can we get these patches to Linus' tree soon? It's annoying to revert
784d5699eddc5 everytime I update my tree.

>> Also note that there's a related fix from Steven:
>> 
>> [PATCH] x86: Fix export for mcount and __fentry__
>> https://marc.info/?l=linux-kernel&m=147733572502413
>> 
>> For compiling the kernel I'm using Ubuntu 12.04:
>> 
>> ii  binutils             2.22-6ubuntu1.4      GNU assembler, linker and binary utilities
>> ii  gcc                  4:4.6.3-1ubuntu5     GNU C compiler
>> 
>> The kernel is running on a separate machine with Ubuntu 14.04.
>> 
>> [  110.703414] bluetooth: disagrees about version of symbol __get_user_2
>> [  110.703416] bluetooth: Unknown symbol __get_user_2 (err -22)
>> [  110.703429] bluetooth: disagrees about version of symbol __put_user_2
>> [  110.703430] bluetooth: Unknown symbol __put_user_2 (err -22)
>> [  110.703579] bluetooth: disagrees about version of symbol __put_user_4
>> [  110.703580] bluetooth: Unknown symbol __put_user_4 (err -22)
>> [  110.703669] bluetooth: disagrees about version of symbol __put_user_1
>> [  110.703670] bluetooth: Unknown symbol __put_user_1 (err -22)
>> [  110.703688] bluetooth: disagrees about version of symbol mcount
>> [  110.703689] bluetooth: Unknown symbol mcount (err -22)
>> 
>
> I haven't seen that one before. Did you definitely make and install new
> modules?

I'm pretty sure modules are correctly installed as I have used the same
procedure for years: on my workstation I do 'make bindeb-pkg', copy the
.deb to the test laptop and install the deb there. Also once I revert
784d5699eddc5 it starts immeadiately working.

-- 
Kalle Valo

[toc] | [prev] | [next] | [standalone]

#1510294

On Thu, 27 Oct 2016 16:14:28 +0300
Kalle Valo <kvalo@codeaurora.org> wrote:

> Nicholas Piggin <npiggin@gmail.com> writes:
> 
> > On Thu, 27 Oct 2016 11:10:03 +0300
> > Kalle Valo <kvalo@codeaurora.org> wrote:
> >  
> >> (Adding Thorsten because of a serious regression and Steven because he
> >> tried to fix something in the same commit)
> >> 
> >> Nicholas Piggin <npiggin@gmail.com> writes:
> >>   
> >> > On Wed, 19 Oct 2016 16:38:14 +0200
> >> > Michal Marek <mmarek@suse.com> wrote:
> >> >    
> >> >> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a):    
> >> >> > We should probably just bring all these arch patches through the
> >> >> > kbuild tree.
> >> >> > 
> >> >> > I'm sorry for the breakage: I didn't realize it broke the build with
> >> >> > some configs, otherwise I would have given Michal a heads up before
> >> >> > his pull request, and worked to get this stuff in first.      
> >> >> 
> >> >> It breaks with some binutils versions only (and only with
> >> >> CONFIG_MODVERSIONS=y, of course).    
> >> >
> >> > Yeah this seems to be the issue, it apparently slipped past all the
> >> > automated builds. It seems like the existing CRC warnings in the tree
> >> > only trigger in rare circumstances too, so something could be a bit
> >> > fragile there.    
> >> 
> >> I upgraded from 4.8 to 4.9-rc2 and noticed that kernel modules fail to
> >> load (log below). After investigating for some time I found this thread
> >> and apparently this is not still fixed, at least not in Linus' tree.
> >> 
> >> Reverting 784d5699eddc5 fixed the issue for me. As I don't see any fix
> >> available (please correct me if I'm wrong) we should just revert that
> >> commit until it's properly fixed.  
> >
> > With these two patches together, does it work for you?
> >
> > http://marc.info/?l=linux-arch&m=147653546809512&w=2
> > http://marc.info/?l=linux-kernel&m=147669851906489&w=2
> >
> > It would be helpful if you could test and let us know, because there seems
> > to be a very tiny number of configs and toolchains that causes
> > problems.  
> 
> With these two patches (on top of ath-201610251249 from ath.git, in
> practice 4.9-rc2 + latest wireless patches) module loading works again.
> If you want you can add my Tested-by:
> 
> Tested-by: Kalle Valo <kvalo@codeaurora.org>

Great, thanks for testing it.

> Can we get these patches to Linus' tree soon? It's annoying to revert
> 784d5699eddc5 everytime I update my tree.

Yes I think it's about ready to merge. Michal is returning from vacation
next week so we should get some progress soon.

> >> Also note that there's a related fix from Steven:
> >> 
> >> [PATCH] x86: Fix export for mcount and __fentry__
> >> https://marc.info/?l=linux-kernel&m=147733572502413
> >> 
> >> For compiling the kernel I'm using Ubuntu 12.04:
> >> 
> >> ii  binutils             2.22-6ubuntu1.4      GNU assembler, linker and binary utilities
> >> ii  gcc                  4:4.6.3-1ubuntu5     GNU C compiler
> >> 
> >> The kernel is running on a separate machine with Ubuntu 14.04.
> >> 
> >> [  110.703414] bluetooth: disagrees about version of symbol __get_user_2
> >> [  110.703416] bluetooth: Unknown symbol __get_user_2 (err -22)
> >> [  110.703429] bluetooth: disagrees about version of symbol __put_user_2
> >> [  110.703430] bluetooth: Unknown symbol __put_user_2 (err -22)
> >> [  110.703579] bluetooth: disagrees about version of symbol __put_user_4
> >> [  110.703580] bluetooth: Unknown symbol __put_user_4 (err -22)
> >> [  110.703669] bluetooth: disagrees about version of symbol __put_user_1
> >> [  110.703670] bluetooth: Unknown symbol __put_user_1 (err -22)
> >> [  110.703688] bluetooth: disagrees about version of symbol mcount
> >> [  110.703689] bluetooth: Unknown symbol mcount (err -22)
> >>   
> >
> > I haven't seen that one before. Did you definitely make and install new
> > modules?  
> 
> I'm pretty sure modules are correctly installed as I have used the same
> procedure for years: on my workstation I do 'make bindeb-pkg', copy the
> .deb to the test laptop and install the deb there. Also once I revert
> 784d5699eddc5 it starts immeadiately working.
> 

Sure, I was just checking because I've seen several types of failure but
not this one before. Thanks for reporting and testing.

Thanks,
Nick

[toc] | [prev] | [next] | [standalone]

#1510231

(Adding Thorsten because of a serious regression and Steven because he
tried to fix something in the same commit)

Nicholas Piggin <npiggin@gmail.com> writes:

> On Wed, 19 Oct 2016 16:38:14 +0200
> Michal Marek <mmarek@suse.com> wrote:
>
>> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a):
>> > We should probably just bring all these arch patches through the
>> > kbuild tree.
>> > 
>> > I'm sorry for the breakage: I didn't realize it broke the build with
>> > some configs, otherwise I would have given Michal a heads up before
>> > his pull request, and worked to get this stuff in first.  
>> 
>> It breaks with some binutils versions only (and only with
>> CONFIG_MODVERSIONS=y, of course).
>
> Yeah this seems to be the issue, it apparently slipped past all the
> automated builds. It seems like the existing CRC warnings in the tree
> only trigger in rare circumstances too, so something could be a bit
> fragile there.

I upgraded from 4.8 to 4.9-rc2 and noticed that kernel modules fail to
load (log below). After investigating for some time I found this thread
and apparently this is not still fixed, at least not in Linus' tree.

Reverting 784d5699eddc5 fixed the issue for me. As I don't see any fix
available (please correct me if I'm wrong) we should just revert that
commit until it's properly fixed.

Also note that there's a related fix from Steven:

[PATCH] x86: Fix export for mcount and __fentry__
https://marc.info/?l=linux-kernel&m=147733572502413

For compiling the kernel I'm using Ubuntu 12.04:

ii  binutils             2.22-6ubuntu1.4      GNU assembler, linker and binary utilities
ii  gcc                  4:4.6.3-1ubuntu5     GNU C compiler

The kernel is running on a separate machine with Ubuntu 14.04.

[  110.703414] bluetooth: disagrees about version of symbol __get_user_2
[  110.703416] bluetooth: Unknown symbol __get_user_2 (err -22)
[  110.703429] bluetooth: disagrees about version of symbol __put_user_2
[  110.703430] bluetooth: Unknown symbol __put_user_2 (err -22)
[  110.703579] bluetooth: disagrees about version of symbol __put_user_4
[  110.703580] bluetooth: Unknown symbol __put_user_4 (err -22)
[  110.703669] bluetooth: disagrees about version of symbol __put_user_1
[  110.703670] bluetooth: Unknown symbol __put_user_1 (err -22)
[  110.703688] bluetooth: disagrees about version of symbol mcount
[  110.703689] bluetooth: Unknown symbol mcount (err -22)

-- 
Kalle Valo

[toc] | [prev] | [next] | [standalone]

#1510341

On Thu, 27 Oct 2016 11:10:03 +0300
Kalle Valo <kvalo@codeaurora.org> wrote:

> (Adding Thorsten because of a serious regression and Steven because he
> tried to fix something in the same commit)
> 
> Nicholas Piggin <npiggin@gmail.com> writes:
> 
> > On Wed, 19 Oct 2016 16:38:14 +0200
> > Michal Marek <mmarek@suse.com> wrote:
> >  
> >> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a):  
> >> > We should probably just bring all these arch patches through the
> >> > kbuild tree.
> >> > 
> >> > I'm sorry for the breakage: I didn't realize it broke the build with
> >> > some configs, otherwise I would have given Michal a heads up before
> >> > his pull request, and worked to get this stuff in first.    
> >> 
> >> It breaks with some binutils versions only (and only with
> >> CONFIG_MODVERSIONS=y, of course).  
> >
> > Yeah this seems to be the issue, it apparently slipped past all the
> > automated builds. It seems like the existing CRC warnings in the tree
> > only trigger in rare circumstances too, so something could be a bit
> > fragile there.  
> 
> I upgraded from 4.8 to 4.9-rc2 and noticed that kernel modules fail to
> load (log below). After investigating for some time I found this thread
> and apparently this is not still fixed, at least not in Linus' tree.
> 
> Reverting 784d5699eddc5 fixed the issue for me. As I don't see any fix
> available (please correct me if I'm wrong) we should just revert that
> commit until it's properly fixed.

With these two patches together, does it work for you?

http://marc.info/?l=linux-arch&m=147653546809512&w=2
http://marc.info/?l=linux-kernel&m=147669851906489&w=2

It would be helpful if you could test and let us know, because there seems
to be a very tiny number of configs and toolchains that causes problems.

> 
> Also note that there's a related fix from Steven:
> 
> [PATCH] x86: Fix export for mcount and __fentry__
> https://marc.info/?l=linux-kernel&m=147733572502413
> 
> For compiling the kernel I'm using Ubuntu 12.04:
> 
> ii  binutils             2.22-6ubuntu1.4      GNU assembler, linker and binary utilities
> ii  gcc                  4:4.6.3-1ubuntu5     GNU C compiler
> 
> The kernel is running on a separate machine with Ubuntu 14.04.
> 
> [  110.703414] bluetooth: disagrees about version of symbol __get_user_2
> [  110.703416] bluetooth: Unknown symbol __get_user_2 (err -22)
> [  110.703429] bluetooth: disagrees about version of symbol __put_user_2
> [  110.703430] bluetooth: Unknown symbol __put_user_2 (err -22)
> [  110.703579] bluetooth: disagrees about version of symbol __put_user_4
> [  110.703580] bluetooth: Unknown symbol __put_user_4 (err -22)
> [  110.703669] bluetooth: disagrees about version of symbol __put_user_1
> [  110.703670] bluetooth: Unknown symbol __put_user_1 (err -22)
> [  110.703688] bluetooth: disagrees about version of symbol mcount
> [  110.703689] bluetooth: Unknown symbol mcount (err -22)
> 

I haven't seen that one before. Did you definitely make and install new
modules?

Thanks,
Nick

[toc] | [prev] | [next] | [standalone]

#1512041

On 27.10.2016 10:10, Kalle Valo wrote:
> (Adding Thorsten because of a serious regression and Steven because he
> tried to fix something in the same commit)

Many thx.

I added this report to the list of regressions for Linux 4.9. I'll
watch this thread for further updates on this issue to document progress
in my weekly reports. Please let me know via regressions@leemhuis.info
in case the discussion moves to a different place (bugzilla or another
mail thread for example).

Current status (afaics): Fix available, waiting for Michal to get back
from vacation.

tia! Ciao, Thorsten

> Nicholas Piggin <npiggin@gmail.com> writes:
> 
>> On Wed, 19 Oct 2016 16:38:14 +0200
>> Michal Marek <mmarek@suse.com> wrote:
>>
>>> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a):
>>>> We should probably just bring all these arch patches through the
>>>> kbuild tree.
>>>>
>>>> I'm sorry for the breakage: I didn't realize it broke the build with
>>>> some configs, otherwise I would have given Michal a heads up before
>>>> his pull request, and worked to get this stuff in first.  
>>>
>>> It breaks with some binutils versions only (and only with
>>> CONFIG_MODVERSIONS=y, of course).
>>
>> Yeah this seems to be the issue, it apparently slipped past all the
>> automated builds. It seems like the existing CRC warnings in the tree
>> only trigger in rare circumstances too, so something could be a bit
>> fragile there.
> 
> I upgraded from 4.8 to 4.9-rc2 and noticed that kernel modules fail to
> load (log below). After investigating for some time I found this thread
> and apparently this is not still fixed, at least not in Linus' tree.
> 
> Reverting 784d5699eddc5 fixed the issue for me. As I don't see any fix
> available (please correct me if I'm wrong) we should just revert that
> commit until it's properly fixed.
> 
> Also note that there's a related fix from Steven:
> 
> [PATCH] x86: Fix export for mcount and __fentry__
> https://marc.info/?l=linux-kernel&m=147733572502413
> 
> For compiling the kernel I'm using Ubuntu 12.04:
> 
> ii  binutils             2.22-6ubuntu1.4      GNU assembler, linker and binary utilities
> ii  gcc                  4:4.6.3-1ubuntu5     GNU C compiler
> 
> The kernel is running on a separate machine with Ubuntu 14.04.
> 
> [  110.703414] bluetooth: disagrees about version of symbol __get_user_2
> [  110.703416] bluetooth: Unknown symbol __get_user_2 (err -22)
> [  110.703429] bluetooth: disagrees about version of symbol __put_user_2
> [  110.703430] bluetooth: Unknown symbol __put_user_2 (err -22)
> [  110.703579] bluetooth: disagrees about version of symbol __put_user_4
> [  110.703580] bluetooth: Unknown symbol __put_user_4 (err -22)
> [  110.703669] bluetooth: disagrees about version of symbol __put_user_1
> [  110.703670] bluetooth: Unknown symbol __put_user_1 (err -22)
> [  110.703688] bluetooth: disagrees about version of symbol mcount
> [  110.703689] bluetooth: Unknown symbol mcount (err -22)
> 

[toc] | [prev] | [next] | [standalone]

#1513318

On 2016-10-18 03:34, Nicholas Piggin wrote:
> Hi Adam,
> 
> Thanks, this is looking good. powerpc will be able to use the generic
> header.
> 
> On Tue, 18 Oct 2016 02:16:26 +0200
> Adam Borowski <kilobyte@angband.pl> wrote:
> 
>> On Mon, Oct 17, 2016 at 02:22:34PM +0200, Mathieu OTHACEHE wrote:
>>>> +#include <asm/uaccess.h>
>>>> +#include <asm/uaccess.h>  
>>>
>>> Included twice.  
>>
>> D'oh!
>>
>>>> +#include <asm/string.h>
>>>> +#include <asm/page.h>
>>>> +#include <asm/checksum.h>
>>>> +
>>>> +#include <asm-generic/asm-prototypes.h>
>>>> +
>>>> +#include <asm/page.h>
>>>> +#include <asm/pgtable.h>
>>>> +#include <asm/special_insns.h>
>>>> +#include <asm/preempt.h>  
>>>
>>> No <asm/arch_hweight.h> for __sw_hweight32 and __sw_hweight64 ?   
>>
>> diff --git a/include/asm-generic/asm-prototypes.h b/include/asm-generic/asm-prototypes.h
>> new file mode 100644
>> index 0000000..df13637
>> --- /dev/null
>> +++ b/include/asm-generic/asm-prototypes.h
>> @@ -0,0 +1,7 @@
>> +#include <linux/bitops.h>
>>
>> ... which has these.
>>
>> Alexey Dobriyan <adobriyan@gmail.com> wrote:
>> } bitops.h is wrong header as well.
>> } Why do you need bitops for bunch of function prototypes?
>>
>> Unless you guys prefer using low-level headers only, that is.
> 
> Well you can't use asm/arch_hweight.h in a generic header of course.
> I would suggest just including linux/ variants where practical for
> the asm-generic/asm-prototypes.h header.
> 
> We should probably just bring all these arch patches through the
> kbuild tree.

Adam,

are you submitting a new version of your x86 asm-prototypes.h patch?

Thanks,
Michal

[toc] | [prev] | [next] | [standalone]

#1513816

On Tue, Nov 01, 2016 at 04:48:48PM +0100, Michal Marek wrote:
> > Adam Borowski <kilobyte@angband.pl> wrote:
> > 
> >> On Mon, Oct 17, 2016 at 02:22:34PM +0200, Mathieu OTHACEHE wrote:
> >>>> +#include <asm/uaccess.h>
> >>>> +#include <asm/uaccess.h>  
> >>>
> >>> Included twice.  
> >>
> >> D'oh!

This appears to be the only thing to fix, right?

> >>>> +#include <asm/string.h>
> >>>> +#include <asm/page.h>
> >>>> +#include <asm/checksum.h>
> >>>> +
> >>>> +#include <asm-generic/asm-prototypes.h>
> >>>> +
> >>>> +#include <asm/page.h>
> >>>> +#include <asm/pgtable.h>
> >>>> +#include <asm/special_insns.h>
> >>>> +#include <asm/preempt.h>  
> >>>
> >>> No <asm/arch_hweight.h> for __sw_hweight32 and __sw_hweight64 ?   
> >>
> >> diff --git a/include/asm-generic/asm-prototypes.h b/include/asm-generic/asm-prototypes.h
> >> new file mode 100644
> >> index 0000000..df13637
> >> --- /dev/null
> >> +++ b/include/asm-generic/asm-prototypes.h
> >> @@ -0,0 +1,7 @@
> >> +#include <linux/bitops.h>
> >>
> >> ... which has these.
> >>
> >> Alexey Dobriyan <adobriyan@gmail.com> wrote:
> >> } bitops.h is wrong header as well.
> >> } Why do you need bitops for bunch of function prototypes?
> >>
> >> Unless you guys prefer using low-level headers only, that is.
> > 
> > Well you can't use asm/arch_hweight.h in a generic header of course.
> > I would suggest just including linux/ variants where practical for
> > the asm-generic/asm-prototypes.h header.
> > 
> > We should probably just bring all these arch patches through the
> > kbuild tree.

I believe inclusion of <linux/bitops.h> is the right thing to do, but if
not, the patch would also need:

extern unsigned int __sw_hweight8(unsigned int w);
extern unsigned int __sw_hweight16(unsigned int w);
extern unsigned int __sw_hweight32(unsigned int w);
extern unsigned long __sw_hweight64(__u64 w);


There's also the issue of mcount/__fentry__, but that's apparently already
dealt with in 5de0a8c, already in mainline.

> are you submitting a new version of your x86 asm-prototypes.h patch?

The update is trivial, but yeah, I can resubmit.  If I'm wrong about where
__sw_hweight{8,16,32,64} should come from, please say so.


Meow!
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

[toc] | [prev] | [next] | [standalone]

#1513818 — [PATCH] kbuild: provide include/asm/asm-prototypes.h for x86

Nicholas Piggin wrote:
> Architectures will need to have an include/asm/asm-prototypes.h that
> defines or #include<>s C-style prototypes for exported asm functions.
> We can do an asm-generic version for the common ones like memset so
> there's not a lot of pointless duplication there.

Signed-off-by: Adam Borowski <kilobyte@angband.pl>
---
 arch/x86/include/asm/asm-prototypes.h | 12 ++++++++++++
 include/asm-generic/asm-prototypes.h  |  7 +++++++
 2 files changed, 19 insertions(+)
 create mode 100644 arch/x86/include/asm/asm-prototypes.h
 create mode 100644 include/asm-generic/asm-prototypes.h

diff --git a/arch/x86/include/asm/asm-prototypes.h b/arch/x86/include/asm/asm-prototypes.h
new file mode 100644
index 0000000..ae87224
--- /dev/null
+++ b/arch/x86/include/asm/asm-prototypes.h
@@ -0,0 +1,12 @@
+#include <asm/ftrace.h>
+#include <asm/uaccess.h>
+#include <asm/string.h>
+#include <asm/page.h>
+#include <asm/checksum.h>
+
+#include <asm-generic/asm-prototypes.h>
+
+#include <asm/page.h>
+#include <asm/pgtable.h>
+#include <asm/special_insns.h>
+#include <asm/preempt.h>
diff --git a/include/asm-generic/asm-prototypes.h b/include/asm-generic/asm-prototypes.h
new file mode 100644
index 0000000..df13637
--- /dev/null
+++ b/include/asm-generic/asm-prototypes.h
@@ -0,0 +1,7 @@
+#include <linux/bitops.h>
+extern void *__memset(void *, int, __kernel_size_t);
+extern void *__memcpy(void *, const void *, __kernel_size_t);
+extern void *__memmove(void *, const void *, __kernel_size_t);
+extern void *memset(void *, int, __kernel_size_t);
+extern void *memcpy(void *, const void *, __kernel_size_t);
+extern void *memmove(void *, const void *, __kernel_size_t);
-- 
2.10.2

[toc] | [prev] | [next] | [standalone]

#1501926 — [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM

This adds an asm/asm-prototypes.h header for ARM to fix the
broken symbol versioning for symbols exported from assembler
files.

In addition to the header, we have to do these other small
changes:

- move the 'extern' declarations out of memset_io/memcpy_io
  to make them visible to the symbol version generator
- move the exports from bitops.h to {change,clear,set,...}bit.S
- move the exports from csumpartialgeneric.S into the files
  including it

I couldn't find the correct prototypes for the compiler builtins,
so I went with the fake 'void f(void)' prototypes that we had
before.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/arch/arm/include/asm/asm-prototypes.h b/arch/arm/include/asm/asm-prototypes.h
new file mode 100644
index 000000000000..04e5616a7b15
--- /dev/null
+++ b/arch/arm/include/asm/asm-prototypes.h
@@ -0,0 +1,34 @@
+#include <linux/arm-smccc.h>
+#include <linux/bitops.h>
+#include <linux/ftrace.h>
+#include <linux/io.h>
+#include <linux/platform_data/asoc-imx-ssi.h>
+#include <linux/string.h>
+#include <linux/uaccess.h>
+
+#include <asm/checksum.h>
+#include <asm/div64.h>
+#include <asm/memory.h>
+
+extern void __aeabi_idivmod(void);
+extern void __aeabi_idiv(void);
+extern void __aeabi_lasr(void);
+extern void __aeabi_llsl(void);
+extern void __aeabi_llsr(void);
+extern void __aeabi_lmul(void);
+extern void __aeabi_uidivmod(void);
+extern void __aeabi_uidiv(void);
+extern void __aeabi_ulcmp(void);
+
+extern void __ashldi3(void);
+extern void __ashrdi3(void);
+extern void __bswapdi2(void);
+extern void __bswapsi2(void);
+extern void __divsi3(void);
+extern void __do_div64(void);
+extern void __lshrdi3(void);
+extern void __modsi3(void);
+extern void __muldi3(void);
+extern void __ucmpdi2(void);
+extern void __udivsi3(void);
+extern void __umodsi3(void);
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 51458d8273ad..fbc3695293cf 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -316,11 +316,13 @@ extern void _memset_io(volatile void __iomem *, int, size_t);
 #define writesw(p,d,l)		__raw_writesw(p,d,l)
 #define writesl(p,d,l)		__raw_writesl(p,d,l)
 
+extern void mmioset(void *, unsigned int, size_t);
+extern void mmiocpy(void *, const void *, size_t);
+
 #ifndef __ARMBE__
 static inline void memset_io(volatile void __iomem *dst, unsigned c,
 	size_t count)
 {
-	extern void mmioset(void *, unsigned int, size_t);
 	mmioset((void __force *)dst, c, count);
 }
 #define memset_io(dst,c,count) memset_io(dst,c,count)
@@ -328,7 +330,6 @@ static inline void memset_io(volatile void __iomem *dst, unsigned c,
 static inline void memcpy_fromio(void *to, const volatile void __iomem *from,
 	size_t count)
 {
-	extern void mmiocpy(void *, const void *, size_t);
 	mmiocpy(to, (const void __force *)from, count);
 }
 #define memcpy_fromio(to,from,count) memcpy_fromio(to,from,count)
@@ -336,7 +337,6 @@ static inline void memcpy_fromio(void *to, const volatile void __iomem *from,
 static inline void memcpy_toio(volatile void __iomem *to, const void *from,
 	size_t count)
 {
-	extern void mmiocpy(void *, const void *, size_t);
 	mmiocpy((void __force *)to, from, count);
 }
 #define memcpy_toio(to,from,count) memcpy_toio(to,from,count)
diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
index df06638b327c..afaef2a7faec 100644
--- a/arch/arm/lib/bitops.h
+++ b/arch/arm/lib/bitops.h
@@ -26,7 +26,6 @@ UNWIND(	.fnstart	)
 	bx	lr
 UNWIND(	.fnend		)
 ENDPROC(\name		)
-EXPORT_SYMBOL(\name	)
 	.endm
 
 	.macro	testop, name, instr, store
@@ -57,7 +56,6 @@ UNWIND(	.fnstart	)
 2:	bx	lr
 UNWIND(	.fnend		)
 ENDPROC(\name		)
-EXPORT_SYMBOL(\name	)
 	.endm
 #else
 	.macro	bitop, name, instr
@@ -77,7 +75,6 @@ UNWIND(	.fnstart	)
 	ret	lr
 UNWIND(	.fnend		)
 ENDPROC(\name		)
-EXPORT_SYMBOL(\name	)
 	.endm
 
 /**
@@ -106,6 +103,5 @@ UNWIND(	.fnstart	)
 	ret	lr
 UNWIND(	.fnend		)
 ENDPROC(\name		)
-EXPORT_SYMBOL(\name	)
 	.endm
 #endif
diff --git a/arch/arm/lib/changebit.S b/arch/arm/lib/changebit.S
index f4027862172f..005fdd18c509 100644
--- a/arch/arm/lib/changebit.S
+++ b/arch/arm/lib/changebit.S
@@ -13,3 +13,4 @@
                 .text
 
 bitop	_change_bit, eor
+EXPORT_SYMBOL(_change_bit)
diff --git a/arch/arm/lib/clearbit.S b/arch/arm/lib/clearbit.S
index f6b75fb64d30..501eff09968d 100644
--- a/arch/arm/lib/clearbit.S
+++ b/arch/arm/lib/clearbit.S
@@ -13,3 +13,4 @@
                 .text
 
 bitop	_clear_bit, bic
+EXPORT_SYMBOL(_clear_bit)
diff --git a/arch/arm/lib/csumpartialcopy.S b/arch/arm/lib/csumpartialcopy.S
index 9c3383fed129..bdcc2eea4e5c 100644
--- a/arch/arm/lib/csumpartialcopy.S
+++ b/arch/arm/lib/csumpartialcopy.S
@@ -49,6 +49,7 @@
 
 #define FN_ENTRY	ENTRY(csum_partial_copy_nocheck)
 #define FN_EXIT		ENDPROC(csum_partial_copy_nocheck)
-#define FN_EXPORT	EXPORT_SYMBOL(csum_partial_copy_nocheck)
 
 #include "csumpartialcopygeneric.S"
+
+EXPORT_SYMBOL(csum_partial_copy_nocheck)
diff --git a/arch/arm/lib/csumpartialcopygeneric.S b/arch/arm/lib/csumpartialcopygeneric.S
index 8b94d20e51d1..06825566c0f7 100644
--- a/arch/arm/lib/csumpartialcopygeneric.S
+++ b/arch/arm/lib/csumpartialcopygeneric.S
@@ -332,4 +332,3 @@ FN_ENTRY
 		mov	r5, r4, get_byte_1
 		b	.Lexit
 FN_EXIT
-FN_EXPORT
diff --git a/arch/arm/lib/csumpartialcopyuser.S b/arch/arm/lib/csumpartialcopyuser.S
index 5d495edf3d83..d5522c94f58c 100644
--- a/arch/arm/lib/csumpartialcopyuser.S
+++ b/arch/arm/lib/csumpartialcopyuser.S
@@ -73,9 +73,9 @@
 
 #define FN_ENTRY	ENTRY(csum_partial_copy_from_user)
 #define FN_EXIT		ENDPROC(csum_partial_copy_from_user)
-#define FN_EXPORT	EXPORT_SYMBOL(csum_partial_copy_from_user)
 
 #include "csumpartialcopygeneric.S"
+EXPORT_SYMBOL(csum_partial_copy_from_user)
 
 /*
  * FIXME: minor buglet here
diff --git a/arch/arm/lib/setbit.S b/arch/arm/lib/setbit.S
index 618fedae4b37..d748b8d1326f 100644
--- a/arch/arm/lib/setbit.S
+++ b/arch/arm/lib/setbit.S
@@ -13,3 +13,4 @@
 		.text
 
 bitop	_set_bit, orr
+EXPORT_SYMBOL(_set_bit)
diff --git a/arch/arm/lib/testchangebit.S b/arch/arm/lib/testchangebit.S
index 4becdc3a59cb..4d2dafa9b787 100644
--- a/arch/arm/lib/testchangebit.S
+++ b/arch/arm/lib/testchangebit.S
@@ -13,3 +13,4 @@
                 .text
 
 testop	_test_and_change_bit, eor, str
+EXPORT_SYMBOL(_test_and_change_bit)
diff --git a/arch/arm/lib/testclearbit.S b/arch/arm/lib/testclearbit.S
index 918841dcce7a..fe5cae2e480a 100644
--- a/arch/arm/lib/testclearbit.S
+++ b/arch/arm/lib/testclearbit.S
@@ -13,3 +13,4 @@
                 .text
 
 testop	_test_and_clear_bit, bicne, strne
+EXPORT_SYMBOL(_test_and_clear_bit)
diff --git a/arch/arm/lib/testsetbit.S b/arch/arm/lib/testsetbit.S
index 8d1b2fe9e487..25fed837edb3 100644
--- a/arch/arm/lib/testsetbit.S
+++ b/arch/arm/lib/testsetbit.S
@@ -13,3 +13,4 @@
                 .text
 
 testop	_test_and_set_bit, orreq, streq
+EXPORT_SYMBOL(_test_and_set_bit)

[toc] | [prev] | [next] | [standalone]

#1503778 — Re: [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM

Dne 17.10.2016 v 14:26 Arnd Bergmann napsal(a):
> This adds an asm/asm-prototypes.h header for ARM to fix the
> broken symbol versioning for symbols exported from assembler
> files.
> 
> In addition to the header, we have to do these other small
> changes:
> 
> - move the 'extern' declarations out of memset_io/memcpy_io
>   to make them visible to the symbol version generator
> - move the exports from bitops.h to {change,clear,set,...}bit.S
> - move the exports from csumpartialgeneric.S into the files
>   including it
> 
> I couldn't find the correct prototypes for the compiler builtins,
> so I went with the fake 'void f(void)' prototypes that we had
> before.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Hi Arnd,

just to make sure I'm looking at the right code - is this based on the
patch by Nick here: https://patchwork.kernel.org/patch/9377783/?

Thanks,
Michal

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web