stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jessica Yu <jeyu@kernel.org>
To: John Stultz <john.stultz@linaro.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>,
	Matthias Maennich <maennich@google.com>,
	Lucas De Marchi <lucas.de.marchi@gmail.com>,
	stable <stable@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] modpost: move the namespace field in Module.symvers last
Date: Wed, 1 Apr 2020 10:00:34 +0200	[thread overview]
Message-ID: <20200401080033.GA12505@linux-8ccs> (raw)
In-Reply-To: <CALAqxLWZ8aET=gHpYUi_v0ez-gDT5nPEnAEb+2uxebFU8D9RXg@mail.gmail.com>

+++ John Stultz [31/03/20 15:09 -0700]:
>On Tue, Mar 31, 2020 at 2:58 AM Jessica Yu <jeyu@kernel.org> wrote:
>> +++ John Stultz [30/03/20 23:25 -0700]:
>> >On Mon, Mar 30, 2020 at 10:49 PM John Stultz <john.stultz@linaro.org> wrote:
>> >> The only difference I can find is that the Module.symvers in the
>> >> external module project doesn't seem to have a tab at the end of each
>> >> line (where as Module.symvers for the kernel - which doesn't seem to
>> >> have any namespace names - does).
>> >>
>> >> Is there something I need to tweak on the external Kbuild to get
>> >> Module.symvers to be generated properly (with the empty tab at the
>> >> end) for this new change?
>> >> Or does the parser need to be a bit more flexible?
>> >>
>> >
>> >One extra clue on this: I noticed the external module Makefile had
>> >KBUILD_EXTRA_SYMBOLS="$(EXTRA_SYMBOLS)"  in the $(MAKE) string, where
>> >EXTRA_SYMBOLS pointed to some files that no longer exist.  I removed
>> >the KBUILD_EXTRA_SYMBOLS= argument, and magically, the generated
>> >Module.symvers now had tabs at the end of each line.
>> >
>> >I wonder if there some path in the KBUILD_EXTRA_SYMBOLS= handling that
>> >isn't generating the output in the same way?
>>
>> I'm afraid we're going to need some specifics on reproducing this
>> issue. Could you provide a reproducer or steps on how to reproduce? I
>> have not been able to trigger this problem even with
>> KBUILD_EXTRA_SYMBOLS pointing to an invalid path (I also tested with
>> valid paths).
>>
>> I tested with a skeleton external module that exports two functions,
>> one with a namespace and one without. I built this module against the
>> latest v5.6 kernel. The generated Module.symvers was correct - the
>> namespaced function had the namespace at the end and the other
>> function without a namespace had a tab at the end.
>>
>> I also tested with two external modules, one with a symbol dependency
>> on the other, so KBUILD_EXTRA_SYMBOLS usage is required here. The
>> generated Module.symvers was also correct here.
>>
>> The only advice I can offer at this time is that all external modules
>> must be built against the new kernel to generate a correctly formated
>> Module.symvers file. If you have any KBUILD_EXTRA_SYMBOLS pointing to
>> an outdated Module.symvers file for example, you will see the "FATAL:
>> parse error in symbol dump file" error.
>
>Well, my apologies.  :(  In the light of day, this isn't reproducing
>anymore. I'm a bit at a loss as to why I was tripping over it so
>regularly before, but I suspect something in the build is leaving a
>stale Modules.symvers around from before this patch landed.
>
>Terribly sorry for the noise.

No problem, thank for reporting back!

Jessica

      reply	other threads:[~2020-04-01  8:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11 17:01 [PATCH v2] modpost: move the namespace field in Module.symvers last Jessica Yu
2020-03-12  7:17 ` Lucas De Marchi
2020-03-14  2:11 ` Masahiro Yamada
2020-03-17  0:24   ` Masahiro Yamada
2020-03-17 11:24   ` Jessica Yu
2020-03-31  5:49 ` John Stultz
2020-03-31  6:25   ` John Stultz
2020-03-31  9:58     ` Jessica Yu
2020-03-31 22:09       ` John Stultz
2020-04-01  8:00         ` Jessica Yu [this message]

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20200401080033.GA12505@linux-8ccs \
    --to=jeyu@kernel.org \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucas.de.marchi@gmail.com \
    --cc=maennich@google.com \
    --cc=stable@vger.kernel.org \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

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

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