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

Groups > linux.debian.kernel > #55878 > unrolled thread

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

Back to article view | Back to linux.debian.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: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Ben Hutchings <ben@decadent.org.uk> - 2016-11-29 02:20 +0100
    Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Nicholas Piggin <npiggin@gmail.com> - 2016-11-29 03:40 +0100
      Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Michal Marek <mmarek@suse.com> - 2016-11-29 10:20 +0100
    Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm Linus Torvalds <torvalds@linux-foundation.org> - 2016-11-29 05:10 +0100
      Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Adam Borowski <kilobyte@angband.pl> - 2016-11-29 14:20 +0100
        Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Ingo Molnar <mingo@kernel.org> - 2016-11-29 14:40 +0100
          Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Adam Borowski <kilobyte@angband.pl> - 2016-11-29 15:30 +0100
        [PATCH] x86/kbuild: enable modversions for symbols exported from asm Adam Borowski <kilobyte@angband.pl> - 2016-11-29 15:00 +0100
          Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm Linus Torvalds <torvalds@linux-foundation.org> - 2016-11-29 16:50 +0100
            Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Michal Marek <mmarek@suse.com> - 2016-11-29 17:20 +0100
              Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm Linus Torvalds <torvalds@linux-foundation.org> - 2016-11-29 17:40 +0100
                Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Ben Hutchings <ben@decadent.org.uk> - 2016-11-29 21:00 +0100
                  Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm Linus Torvalds <torvalds@linux-foundation.org> - 2016-11-29 22:00 +0100
                    Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm Linus Torvalds <torvalds@linux-foundation.org> - 2016-11-30 20:00 +0100
                      Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Ben Hutchings <ben@decadent.org.uk> - 2016-11-30 22:40 +0100
                        Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Nicholas Piggin <npiggin@gmail.com> - 2016-12-01 03:20 +0100
                          Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Ben Hutchings <ben@decadent.org.uk> - 2016-12-01 03:40 +0100
                            Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Nicholas Piggin <npiggin@gmail.com> - 2016-12-01 05:00 +0100
                              Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Michal Marek <mmarek@suse.com> - 2016-12-01 17:40 +0100
                                Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Hannes Frederic Sowa <hannes@stressinduktion.org> - 2016-12-02 16:00 +0100
                                Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Nicholas Piggin <npiggin@gmail.com> - 2016-12-09 05:00 +0100
                                  Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Ian Campbell <ijc@hellion.org.uk> - 2016-12-09 16:30 +0100
                                    Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Nicholas Piggin <npiggin@gmail.com> - 2016-12-09 17:40 +0100
                                      Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-12-10 14:00 +0100
                                        Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Nicholas Piggin <npiggin@gmail.com> - 2016-12-12 05:10 +0100
                                        Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Ian Campbell <ijc@hellion.org.uk> - 2016-12-12 10:10 +0100
                                        Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Don Zickus <dzickus@redhat.com> - 2016-12-14 19:20 +0100
                                      Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Stanislav Kozina <skozina@redhat.com> - 2016-12-13 02:30 +0100
                                      Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Michal Marek <mmarek@suse.com> - 2016-12-14 00:10 +0100
                                        Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm Dodji Seketeli <dodji@seketeli.org> - 2016-12-14 10:20 +0100
                                          Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Michal Marek <mmarek@suse.com> - 2016-12-14 10:40 +0100
                                            Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Michal Marek <mmarek@suse.com> - 2016-12-14 11:00 +0100
                                            Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm Dodji Seketeli <dodji@seketeli.org> - 2016-12-14 11:00 +0100
                                              Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Michal Marek <mmarek@suse.com> - 2016-12-14 11:10 +0100
                                                Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm Dodji Seketeli <dodji@seketeli.org> - 2016-12-14 11:20 +0100
                                                  Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Michal Marek <mmarek@suse.com> - 2016-12-14 11:40 +0100
                                              Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm Dodji Seketeli <dodji@seketeli.org> - 2016-12-14 11:20 +0100
                      Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Don Zickus <dzickus@redhat.com> - 2016-12-01 05:50 +0100
                        Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Nicholas Piggin <npiggin@gmail.com> - 2016-12-01 05:50 +0100
                          Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Don Zickus <dzickus@redhat.com> - 2016-12-01 16:40 +0100
                            Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Don Zickus <dzickus@redhat.com> - 2016-12-01 17:00 +0100
                              Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-12-01 17:40 +0100
                                Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Don Zickus <dzickus@redhat.com> - 2016-12-01 20:10 +0100
                            Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Christoph Hellwig <hch@infradead.org> - 2016-12-01 17:10 +0100
                            Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Nicholas Piggin <npiggin@gmail.com> - 2016-12-09 05:10 +0100
                              Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Stanislav Kozina <skozina@redhat.com> - 2016-12-09 09:20 +0100
                                Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Nicholas Piggin <npiggin@gmail.com> - 2016-12-09 09:40 +0100
                                  Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Stanislav Kozina <skozina@redhat.com> - 2016-12-09 16:00 +0100
                                    Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Nicholas Piggin <npiggin@gmail.com> - 2016-12-09 17:20 +0100
                                      Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-12-09 17:30 +0100
                                        Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Stanislav Kozina <skozina@redhat.com> - 2016-12-12 11:10 +0100
                                          Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Nicholas Piggin <npiggin@gmail.com> - 2016-12-13 08:50 +0100
                                        Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Hannes Frederic Sowa <hannes@redhat.com> - 2016-12-14 15:40 +0100
                                          Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Nicholas Piggin <npiggin@gmail.com> - 2016-12-15 03:30 +0100
                                            Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Hannes Frederic Sowa <hannes@redhat.com> - 2016-12-15 12:40 +0100
                                              Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Nicholas Piggin <npiggin@gmail.com> - 2016-12-15 13:30 +0100
                                                Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Hannes Frederic Sowa <hannes@redhat.com> - 2016-12-15 14:40 +0100
                                                  Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Nicholas Piggin <npiggin@gmail.com> - 2016-12-15 15:40 +0100
                                                    Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Hannes Frederic Sowa <hannes@redhat.com> - 2016-12-15 16:40 +0100
                                                Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Stanislav Kozina <skozina@redhat.com> - 2016-12-15 15:00 +0100
                              Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Don Zickus <dzickus@redhat.com> - 2016-12-09 17:40 +0100
                        Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Stanislav Kozina <skozina@redhat.com> - 2016-12-01 12:20 +0100
                          Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Nicholas Piggin <npiggin@gmail.com> - 2016-12-01 12:30 +0100
                            Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Stanislav Kozina <skozina@redhat.com> - 2016-12-01 13:00 +0100
                              Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Nicholas Piggin <npiggin@gmail.com> - 2016-12-01 14:00 +0100
                            Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm Dodji Seketeli <dodji@seketeli.org> - 2016-12-01 16:50 +0100
                        Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Michal Marek <mmarek@suse.com> - 2016-12-01 17:40 +0100
            Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Adam Borowski <kilobyte@angband.pl> - 2016-11-29 18:10 +0100
              Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm Linus Torvalds <torvalds@linux-foundation.org> - 2016-11-29 18:30 +0100
                Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm Linus Torvalds <torvalds@linux-foundation.org> - 2016-11-29 18:40 +0100
                  Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm Arnd Bergmann <arnd@arndb.de> - 2016-12-01 15:20 +0100
                    Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Michal Marek <mmarek@suse.com> - 2016-12-01 17:40 +0100
                    Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm Linus Torvalds <torvalds@linux-foundation.org> - 2016-12-01 19:50 +0100
                      Re: [RFC, PATCH, v3.9] default exported asm symbols to zero Geert Uytterhoeven <geert@linux-m68k.org> - 2016-12-02 14:00 +0100
                        Re: [RFC, PATCH, v3.9] default exported asm symbols to zero Arnd Bergmann <arnd@arndb.de> - 2016-12-02 16:10 +0100
                      Re: [RFC, PATCH, v3.9] default exported asm symbols to zero Adam Borowski <kilobyte@angband.pl> - 2016-12-02 16:40 +0100
                      Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm Linus Torvalds <torvalds@linux-foundation.org> - 2016-12-02 18:30 +0100
                      Re: [RFC, PATCH, v3.9] default exported asm symbols to zero Ben Hutchings <ben@decadent.org.uk> - 2016-12-03 05:40 +0100
                        Re: [RFC, PATCH, v3.9] default exported asm symbols to zero Arnd Bergmann <arnd@arndb.de> - 2016-12-03 12:10 +0100
                      Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Alan Modra <amodra@gmail.com> - 2016-12-04 09:20 +0100
                        Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm Linus Torvalds <torvalds@linux-foundation.org> - 2016-12-04 22:10 +0100
                Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Michal Marek <mmarek@suse.com> - 2016-11-29 22:50 +0100
          Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Ben Hutchings <ben@decadent.org.uk> - 2016-12-02 03:10 +0100
            Re: [PATCH] x86/kbuild: enable modversions for symbols exported from  asm Adam Borowski <kilobyte@angband.pl> - 2016-12-02 12:30 +0100
              Re: [PATCH] x86/kbuild: enable modversions for symbols exported  from asm Ben Hutchings <ben@decadent.org.uk> - 2016-12-02 16:10 +0100

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#56072 — Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Fri, Dec 09, 2016 at 01:50:41PM +1000, Nicholas Piggin wrote:
> > 
> > We have plenty of customers with 10 year old drivers, where the expertise
> > has long left the company.  The engineers still around, recompile and make
> > tweaks to get things working on the latest RHEL.  Verify it passes testing
> > and release it.  Then they hope to not touch it again for a few years until
> > the next RHEL comes along.
> > 
> > Scary, huh? :-)
> 
> Oh yeah my aim here is not to make distro or out of tree module vendors
> life harder, actually the opposite. If it turns out modversions really is
> the best approach, I'm not in a position to complain about its complexity
> because we have Suse and Redhat people maintaining the build and module
> systems :) I just want to see if we can do things better.

Hi Nick,

I think we are in pretty good agreement here.  We can do better than
modversions.  On the flip side, I would hate to see modversions ripped out
until we have an alternate path forward as it does get us by for now. :-)

Cheers,
Don

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

#55910 — Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On 12/01/2016 05:13 AM, Don Zickus wrote:

...

> I think GregKH pointed to one such tool, libabigail?  We are working on
> others too.

I should mention one of the others here:
https://github.com/skozina/kabi-dw

It's quite comparable to libabigail in the way it works, the main 
differences are:
  - written in pure C
  - depends only on elf-utils and flex/yacc
  - it's much simpler (4k LOC)
  - stores the type information in the text files and compares those 
instead of directly comparing two sets of DWARF data

Regards,
-Stanislav

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

#55911

On Thu, 1 Dec 2016 11:48:09 +0100
Stanislav Kozina <skozina@redhat.com> wrote:

> On 12/01/2016 05:13 AM, Don Zickus wrote:
> 
> ...
> 
> > I think GregKH pointed to one such tool, libabigail?  We are working on
> > others too.  
> 
> I should mention one of the others here:
> https://github.com/skozina/kabi-dw
> 
> It's quite comparable to libabigail in the way it works, the main 
> differences are:
>   - written in pure C
>   - depends only on elf-utils and flex/yacc
>   - it's much simpler (4k LOC)
>   - stores the type information in the text files and compares those 
> instead of directly comparing two sets of DWARF data

Now this seems much better for distro ABI checking.

The next question is, do they need any kernel support for rare cases
where they do have to break the ABI of an export? Simple rename of the
function with a _v2 postfix might be enough. We could retain some per
symbol versioning in the kernel if needed, but how much would it
actually help?

Thanks,
Nick

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

#55912 — Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On 12/01/2016 12:09 PM, Nicholas Piggin wrote:
> On Thu, 1 Dec 2016 11:48:09 +0100
> Stanislav Kozina <skozina@redhat.com> wrote:
>
>> On 12/01/2016 05:13 AM, Don Zickus wrote:
>>
>> ...
>>
>>> I think GregKH pointed to one such tool, libabigail?  We are working on
>>> others too.
>> I should mention one of the others here:
>> https://github.com/skozina/kabi-dw
>>
>> It's quite comparable to libabigail in the way it works, the main
>> differences are:
>>    - written in pure C
>>    - depends only on elf-utils and flex/yacc
>>    - it's much simpler (4k LOC)
>>    - stores the type information in the text files and compares those
>> instead of directly comparing two sets of DWARF data
> Now this seems much better for distro ABI checking.
>
> The next question is, do they need any kernel support for rare cases
> where they do have to break the ABI of an export? Simple rename of the
> function with a _v2 postfix might be enough. We could retain some per
> symbol versioning in the kernel if needed, but how much would it
> actually help?

The biggest pain point AFAICT is to identify what types (functions, 
structs, enums, ...) should be considered a part of the stable ABI. And 
the problem with modversions is that it pulls in just everything which 
gets (accidentally?) #included in the source file.
The actual ABI maintenance is a different problem, but there are many 
possible approaches, the _v2 suffix being one of them.

Regards,
-Stanislav

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

#55913

On Thu, 1 Dec 2016 12:33:02 +0100
Stanislav Kozina <skozina@redhat.com> wrote:

> On 12/01/2016 12:09 PM, Nicholas Piggin wrote:
> > On Thu, 1 Dec 2016 11:48:09 +0100
> > Stanislav Kozina <skozina@redhat.com> wrote:
> >  
> >> On 12/01/2016 05:13 AM, Don Zickus wrote:
> >>
> >> ...
> >>  
> >>> I think GregKH pointed to one such tool, libabigail?  We are working on
> >>> others too.  
> >> I should mention one of the others here:
> >> https://github.com/skozina/kabi-dw
> >>
> >> It's quite comparable to libabigail in the way it works, the main
> >> differences are:
> >>    - written in pure C
> >>    - depends only on elf-utils and flex/yacc
> >>    - it's much simpler (4k LOC)
> >>    - stores the type information in the text files and compares those
> >> instead of directly comparing two sets of DWARF data  
> > Now this seems much better for distro ABI checking.
> >
> > The next question is, do they need any kernel support for rare cases
> > where they do have to break the ABI of an export? Simple rename of the
> > function with a _v2 postfix might be enough. We could retain some per
> > symbol versioning in the kernel if needed, but how much would it
> > actually help?  
> 
> The biggest pain point AFAICT is to identify what types (functions, 
> structs, enums, ...) should be considered a part of the stable ABI.

Sure. This is something an automated checker can't solve completely.
Any changes would have to be considered in terms of their impact to
the ABI. It's not just data but also instruction changes involved.

This is policy that should not be mandated by the kernel. Which is
why I'm in favor of using tools like this and just providing mechanism
so distros can implement their own polices.

> And 
> the problem with modversions is that it pulls in just everything which 
> gets (accidentally?) #included in the source file.

I think that's SRCVERSION which is something else. But modversions
has problems too.

> The actual ABI maintenance is a different problem, but there are many 
> possible approaches, the _v2 suffix being one of them.

Would be good to get a consensus on that too.

Thanks,
Nick

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

#55922 — Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

Nicholas Piggin <npiggin@gmail.com> a écrit:

[...]

> On Thu, 1 Dec 2016 11:48:09 +0100
> Stanislav Kozina <skozina@redhat.com> wrote:
>
>> On 12/01/2016 05:13 AM, Don Zickus wrote:
>> 
>> ...
>> 
>> > I think GregKH pointed to one such tool, libabigail?  We are working on
>> > others too.  
>> 
>> I should mention one of the others here:
>> https://github.com/skozina/kabi-dw

[...]

> Now this seems much better for distro ABI checking.

Right, Incidentally, Fedora does distro-wide ABI verfication for
userspace libraries updates in a given stable distribution.  You can
look at an example of output of the libabigail-based tool that compares
a new version of an ELF library to it's latest stable version:

https://taskotron.fedoraproject.org/artifacts/all/a55cbac8-ab64-11e6-94e0-525400120b80/task_output/curl-7.51.0-2.fc25.log

The results of those ABI comparison can browsed at https://taskotron.fedoraproject.org/resultsdb/results?testcase_name=dist.abicheck.

Of course, you can run the comparison yourself by using a
libabigail-based tool like
https://sourceware.org/libabigail/manual/abipkgdiff.html which takes
.deb and .rpm packages.

We are currently working on making libabigail-based tools understand
Linux kernel specifities so that we can run that kind of analysis on
Kernel updates too.  Ideally, when this is done, you should be able to
just use abipkgdiff on two Linux Kernel packages and get the same kind
of output.

> The next question is, do they need any kernel support for rare cases
> where they do have to break the ABI of an export? Simple rename of the
> function with a _v2 postfix might be enough. We could retain some per
> symbol versioning in the kernel if needed, but how much would it
> actually help?

As a reviewer of the ABI change report emitted by the tool, if what you
want is to say "I reviewed that ABI change and it's OK, so please do not
show it to me next time", then you can feed the tool with a "suppression
specification".  It's a text file in the INI syntax in which you can
specify the kind of change you want the tool to suppress from its
output: https://sourceware.org/libabigail/manual/libabigail-concepts.html.

So I don't think you need to do anything to the source code of the
Kernel in the cases where you need to change the ABI.  Just tell the
tool about that change.

Cheers,

-- 
		Dodji

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

#55925 — Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On 2016-12-01 05:13, Don Zickus wrote:
> Sorry for chiming in late, but yes RHEL is a big user of MODVERSIONS for our
> kabi protection work.  Despite our best intentions we still have lots of
> partners and customers that provide value-add out-of-tree drivers to their
> customers.  These module builders requested we have a mechanism to allow
> rolling modules forward for each of our minor RHEL updates without breaking
> their drivers.

FWIW, in SLES we use CONFIG_MODVERSION for pretty much the same reasons
you listed. We also enable it in openSUSE, but there it's not as crucial.

Michal

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

#55895 — Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Tue, Nov 29, 2016 at 07:27:12AM -0800, Linus Torvalds wrote:
> On Nov 29, 2016 5:51 AM, "Adam Borowski" <kilobyte@angband.pl> wrote:
> > >
> > >  (a) tested
> >
> > By many people.
> 
> No.
> 
> I've tested the build *without* this, and it works fine.

Michal mentioned "why", let's try "where".

I have no idea what setup is required to trigger the problem, but here's a
simple sufficient one:

Current Debian unstable, amd64.
git reset --hard v4.9-rc7
git revert cd3caefb
make defconfig
CONFIG_MODVERSIONS=y
(in my case) CONFIG_BTRFS_FS=y (so I can boot)
enable a module for testing, I used CONFIG_EXT4_FS=m
make bindeb-pkg
dpkg -i linux-image_XXXXX.deb

modprobe ext4
[   63.779490] jbd2: no symbol version for memcpy
[   63.779492] jbd2: Unknown symbol memcpy (err -22)
[   63.779550] jbd2: no symbol version for phys_base
[   63.779551] jbd2: Unknown symbol phys_base (err -22)
[   63.779561] jbd2: no symbol version for memset
[   63.779562] jbd2: Unknown symbol memset (err -22)

Not sure which piece of toolchain matters here, someone said binutils.
In that case, Fedora ships 2.26.1-1.fc25, they were frozen so couldn't
update.  Debian is at 2.27.51.20161127-1, Gentoo at 2.27, same for Arch,
OpenSUSE; Ubuntu at 2.27.51.20161124-1.

Thus, if it's indeed binutils, you'll see the breakage as soon as Fedora
recovers from the freeze.


Meow!
-- 
The bill declaring Jesus as the King of Poland fails to specify whether
the addition is at the top or end of the list of kings.  What should the
historians do?

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

#55896 — Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Multipart message — attachments visible in raw view] — view raw

On Tue, Nov 29, 2016 at 9:05 AM, Adam Borowski <kilobyte@angband.pl> wrote:
>
> Thus, if it's indeed binutils, you'll see the breakage as soon as Fedora
> recovers from the freeze.

So quite frankly, I don't want to make our kernel sources worse due to
broken shit tools getting something wrong that we shouldn't even care
about.

How about this stupid patch? It weakens modversions, but that may be
ok for Debian, and a better alternative than just saying "we don't
support it at all".

            Linus

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

#55897 — Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Tue, Nov 29, 2016 at 9:10 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So quite frankly, I don't want to make our kernel sources worse due to
> broken shit tools getting something wrong that we shouldn't even care
> about.

And yes, I'm on binutils 2.26 (with no issues), so it could be that
it's 2.27 that triggers this.

We could make the pr_warn_once() mention "broken binutils?" so that
people know why the warning happens.

           Linus

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

#55917 — Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Tuesday, November 29, 2016 9:14:46 AM CET Linus Torvalds wrote:
> On Tue, Nov 29, 2016 at 9:10 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > So quite frankly, I don't want to make our kernel sources worse due to
> > broken shit tools getting something wrong that we shouldn't even care
> > about.
> 
> And yes, I'm on binutils 2.26 (with no issues), so it could be that
> it's 2.27 that triggers this.
> 
> We could make the pr_warn_once() mention "broken binutils?" so that
> people know why the warning happens.

I've tried to get to the bottom of this, but couldn't find anything
related to the toolchain version. I've tried binutils 2.23, 2.24, 2.26
and 2.27, and also gcc-7.0, gcc-5.4.1 and gcc-4.9.3, but with today's
linux-next, I always get

WARNING: EXPORT symbol "mcount" [arch/x86/entry/built-in.ko] version generation failed, symbol will not be versioned.
WARNING: EXPORT symbol "mcount" [arch/x86/built-in.ko] version generation failed, symbol will not be versioned.
WARNING: EXPORT symbol "cmpxchg8b_emu" [vmlinux] version generation failed, symbol will not be versioned.
WARNING: EXPORT symbol "empty_zero_page" [vmlinux] version generation failed, symbol will not be versioned.
WARNING: EXPORT symbol "mcount" [vmlinux] version generation failed, symbol will not be versioned.
WARNING: EXPORT symbol "cmpxchg8b_emu" [vmlinux] version generation failed, symbol will not be versioned.
WARNING: EXPORT symbol "empty_zero_page" [vmlinux] version generation failed, symbol will not be versioned.
WARNING: EXPORT symbol "mcount" [vmlinux] version generation failed, symbol will not be versioned.

Out of 12 randconfig builds that had CONFIG_MODVERSIONS enabled, all 12
had this problem, though not always with all the symbols.

	Arnd

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

#55926 — Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On 2016-12-01 14:58, Arnd Bergmann wrote:
> On Tuesday, November 29, 2016 9:14:46 AM CET Linus Torvalds wrote:
>> On Tue, Nov 29, 2016 at 9:10 AM, Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>>>
>>> So quite frankly, I don't want to make our kernel sources worse due to
>>> broken shit tools getting something wrong that we shouldn't even care
>>> about.
>>
>> And yes, I'm on binutils 2.26 (with no issues), so it could be that
>> it's 2.27 that triggers this.
>>
>> We could make the pr_warn_once() mention "broken binutils?" so that
>> people know why the warning happens.
> 
> I've tried to get to the bottom of this, but couldn't find anything
> related to the toolchain version. I've tried binutils 2.23, 2.24, 2.26
> and 2.27, and also gcc-7.0, gcc-5.4.1 and gcc-4.9.3, but with today's
> linux-next, I always get
> 
> WARNING: EXPORT symbol "mcount" [arch/x86/entry/built-in.ko] version generation failed, symbol will not be versioned.
> WARNING: EXPORT symbol "mcount" [arch/x86/built-in.ko] version generation failed, symbol will not be versioned.
> WARNING: EXPORT symbol "cmpxchg8b_emu" [vmlinux] version generation failed, symbol will not be versioned.
> WARNING: EXPORT symbol "empty_zero_page" [vmlinux] version generation failed, symbol will not be versioned.
> WARNING: EXPORT symbol "mcount" [vmlinux] version generation failed, symbol will not be versioned.
> WARNING: EXPORT symbol "cmpxchg8b_emu" [vmlinux] version generation failed, symbol will not be versioned.
> WARNING: EXPORT symbol "empty_zero_page" [vmlinux] version generation failed, symbol will not be versioned.
> WARNING: EXPORT symbol "mcount" [vmlinux] version generation failed, symbol will not be versioned.
> 
> Out of 12 randconfig builds that had CONFIG_MODVERSIONS enabled, all 12
> had this problem, though not always with all the symbols.

That we are not generating modversions for the asm exports is a known
problem, independent of the toolchain. The problem with some toolchains
(presumably, because that's the next thing to blame if the source and
the .config is identical) is that the CRCs do not appear as 0 in the
___kcrctab/___kcrctab_gpl section.

Michal

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

#55929 — Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Thu, Dec 1, 2016 at 5:58 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> WARNING: EXPORT symbol "mcount" [arch/x86/entry/built-in.ko] version generation failed, symbol will not be versioned.
> WARNING: EXPORT symbol "mcount" [arch/x86/built-in.ko] version generation failed, symbol will not be versioned.
> WARNING: EXPORT symbol "cmpxchg8b_emu" [vmlinux] version generation failed, symbol will not be versioned.
> WARNING: EXPORT symbol "empty_zero_page" [vmlinux] version generation failed, symbol will not be versioned.
> WARNING: EXPORT symbol "mcount" [vmlinux] version generation failed, symbol will not be versioned.
> WARNING: EXPORT symbol "cmpxchg8b_emu" [vmlinux] version generation failed, symbol will not be versioned.
> WARNING: EXPORT symbol "empty_zero_page" [vmlinux] version generation failed, symbol will not be versioned.
> WARNING: EXPORT symbol "mcount" [vmlinux] version generation failed, symbol will not be versioned.
>
> Out of 12 randconfig builds that had CONFIG_MODVERSIONS enabled, all 12
> had this problem, though not always with all the symbols.

Well, the good news is that pretty fundamentally, if it's just the asm
symbls, those really don't have ABI's that change (or if they change,
it's such a fundamental change that everything else will likely have
changed too and we don't need to worry about one asm symbol crc - the
change will be caught by other symbols).

So I think the whole "we don't really care" approach should work fine.
The "let's make every symbol always be versioned" may just be too much
pain for no real gain.

            Linus

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

#55940 — Re: [RFC, PATCH, v3.9] default exported asm symbols to zero

On Fri, Dec 2, 2016 at 1:40 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> With binutils-2.16 and before, a weak missing symbol was kept during the

2.26?

> final link, and a missing CRC for an export would lead to that CRC
> being treated as zero implicitly. With binutils-2.17, the crc

2.27?

> symbol gets dropped, and any module trying to use it will fail to
> load.

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]

#55943 — Re: [RFC, PATCH, v3.9] default exported asm symbols to zero

On Friday, December 2, 2016 1:59:15 PM CET Geert Uytterhoeven wrote:
> On Fri, Dec 2, 2016 at 1:40 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > With binutils-2.16 and before, a weak missing symbol was kept during the
> 
> 2.26?
> 
> > final link, and a missing CRC for an export would lead to that CRC
> > being treated as zero implicitly. With binutils-2.17, the crc
> 
> 2.27?'

Yes, serious version number deficiency on my end. Also 4.9 instead of 3.9
in the subject...

	Arnd

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

#55945 — Re: [RFC, PATCH, v3.9] default exported asm symbols to zero

On Fri, Dec 02, 2016 at 01:40:27PM +0100, Arnd Bergmann wrote:
> With binutils-2.16 and before, a weak missing symbol was kept during the
> final link, and a missing CRC for an export would lead to that CRC
> being treated as zero implicitly. With binutils-2.17, the crc
> symbol gets dropped, and any module trying to use it will fail to
> load.
> 
> This sets the weak CRC symbol to zero explicitly, making it defined
> in vmlinux, which in turn lets us load the modules referring to
> that CRC.
> 
> The comment above the __CRC_SYMBOL macro suggests that this was
> always the intention, although it also seems that all symbols
> defined in C have a correct CRC these days, and only the exports
> that are now done in assembly need this.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---

Looks good, works for me, and, unlike faaae2a5, doesn't produce a nasty
user-scaring warning in normal operation.

> diff --git a/include/asm-generic/export.h b/include/asm-generic/export.h
> index 63554e9..59a3b2f 100644
> --- a/include/asm-generic/export.h
> +++ b/include/asm-generic/export.h
> @@ -54,6 +54,7 @@ KSYM(__kstrtab_\name):
>  KSYM(__kcrctab_\name):
>  	__put KSYM(__crc_\name)
>  	.weak KSYM(__crc_\name)
> +	.set KSYM(__crc_\name), 0
>  	.previous
>  #endif
>  #endif

-- 
The bill declaring Jesus as the King of Poland fails to specify whether
the addition is at the top or end of the list of kings.  What should the
historians do?

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

#55946 — Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Fri, Dec 2, 2016 at 2:55 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> Yes, it's always been just the assembly symbols that broke, these were
> the ones that Al's original patch changed and that ended up with
> no version information.

Ok, and the reason is because even if we have a weak symbol from C, it
would always have a value.

Good to know what the heck the problem was.

> I have managed to bisect the link failure to a specific binutils
> commit by Alan Modra now:

Thanks. And I committed your "set to zero" patch, so we can hopefully
leave this all behind us.

I marked it for stable (not because older kernels need it, but because
it's the right thing to do and if we ever backport anything that
causes this we don't want to forget this).

And I'll keep the workaround in kernel/module.c just because it's
really late in the rc series, and I'd rather have both belt and
suspenders for this all right now.

               Linus

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

#55957 — Re: [RFC, PATCH, v3.9] default exported asm symbols to zero

[Multipart message — attachments visible in raw view] — view raw

On Fri, 2016-12-02 at 13:40 +0100, Arnd Bergmann wrote:
> With binutils-2.16 and before, a weak missing symbol was kept during the
> final link, and a missing CRC for an export would lead to that CRC
> being treated as zero implicitly. With binutils-2.17, the crc
> symbol gets dropped, and any module trying to use it will fail to
> load.
> 
> This sets the weak CRC symbol to zero explicitly, making it defined
> in vmlinux, which in turn lets us load the modules referring to
> that CRC.
> 
> The comment above the __CRC_SYMBOL macro suggests that this was
> always the intention, although it also seems that all symbols
> defined in C have a correct CRC these days, and only the exports
> that are now done in assembly need this.
> 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Not sure if this is the correct way of doing it, but this seems trivial
> enough and lets me build the kernel with missing CRCs with any binutils
> version.

I tried this along with Adam's patch on x86_64, with Debian's binutils
2.27.51.20161127.  The result was that the kernel's __kcrctab held 0
for several symbols, even though there was type information in asm-
prototypes.h and Module.symvers and the modules had a non-zero CRC for
those symbols.  With just Adam's patch, the kernel and modules agreed.

Ben.

> diff --git a/include/asm-generic/export.h b/include/asm-generic/export.h
> index 63554e9..59a3b2f 100644
> --- a/include/asm-generic/export.h
> +++ b/include/asm-generic/export.h
> @@ -54,6 +54,7 @@ KSYM(__kstrtab_\name):
>  KSYM(__kcrctab_\name):
> >  	__put KSYM(__crc_\name)
> >  	.weak KSYM(__crc_\name)
> > +	.set KSYM(__crc_\name), 0
> >  	.previous
>  #endif
>  #endif
> 
-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer

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

#55961 — Re: [RFC, PATCH, v3.9] default exported asm symbols to zero

On Saturday, December 3, 2016 4:36:37 AM CET Ben Hutchings wrote:
> On Fri, 2016-12-02 at 13:40 +0100, Arnd Bergmann wrote:
> > With binutils-2.16 and before, a weak missing symbol was kept during the
> > final link, and a missing CRC for an export would lead to that CRC
> > being treated as zero implicitly. With binutils-2.17, the crc
> > symbol gets dropped, and any module trying to use it will fail to
> > load.
> > 
> > This sets the weak CRC symbol to zero explicitly, making it defined
> > in vmlinux, which in turn lets us load the modules referring to
> > that CRC.
> > 
> > The comment above the __CRC_SYMBOL macro suggests that this was
> > always the intention, although it also seems that all symbols
> > defined in C have a correct CRC these days, and only the exports
> > that are now done in assembly need this.
> > 
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > Not sure if this is the correct way of doing it, but this seems trivial
> > enough and lets me build the kernel with missing CRCs with any binutils
> > version.
> 
> I tried this along with Adam's patch on x86_64, with Debian's binutils
> 2.27.51.20161127.  The result was that the kernel's __kcrctab held 0
> for several symbols, even though there was type information in asm-
> prototypes.h and Module.symvers and the modules had a non-zero CRC for
> those symbols.  With just Adam's patch, the kernel and modules agreed.

Can you be more specific? Which symbols are those? I would have expected
modpost to generate Module.symvers from the vmlinux file, so I wonder
where that difference comes from.

	Arnd

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

#55989 — Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Fri, Dec 02, 2016 at 11:55:58AM +0100, Arnd Bergmann wrote:
> I have managed to bisect the link failure to a specific binutils
> commit by Alan Modra now:
> 
> d983c8c ("Strip undefined symbols from .symtab")
> 
> went into binutils-2_26 and was reverted in 
> 
> a82e3ef ("Revert "Strip undefined symbols from .symtab"")
> 
> after the release branch for 2.26 was started, so that version
> ended up being fine. However, the 2.27 version never saw the revert
> and causes loadable kernel modules to become unusable when they refer
> to a weak symbol in vmlinux. This works with 2.26 and lower:

See https://sourceware.org/ml/binutils/2016-01/msg00118.html thread
for discussion on why the patch was reverted for 2.26.  At the time I
believed that only the ppc64 kernel was affected, by a weak undefined
"__crc_TOC." disappearing.  Am I correct in thinking that remained
true up until Linus' merge commit 84d69848c9 2016-10-14?

As far as reverting the binutils commit goes, I'm quite willing to do
that if necessary.  You can see how important I think the fix was by
viewing https://sourceware.org/bugzilla/show_bug.cgi?id=4317 and
noticing that the bug was reported in 2007 and didn't see any action
for 8 years..

-- 
Alan Modra
Australia Development Lab, IBM

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

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | linux.debian.kernel

csiph-web