From: Jessica Yu <jeyu@kernel.org>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: Module loading problem since 5.3
Date: Mon, 14 Oct 2019 12:01:44 +0200 [thread overview]
Message-ID: <20191014100143.GA6525@linux-8ccs> (raw)
In-Reply-To: <875eecfb-618a-4989-3b9f-f8272b8d3746@gmail.com>
+++ Heiner Kallweit [11/10/19 21:26 +0200]:
>On 10.10.2019 19:15, Luis Chamberlain wrote:
>>
>>
>> On Thu, Oct 10, 2019, 6:50 PM Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> wrote:
>>
>> MODULE_SOFTDEP("pre: realtek")
>>
>> Are you aware of any current issues with module loading
>> that could cause this problem?
>>
>>
>> Nope. But then again I was not aware of MODULE_SOFTDEP(). I'd encourage an extension to lib/kmod.c or something similar which stress tests this. One way that comes to mind to test this is to allow a new tests case which loads two drives which co depend on each other using this macro. That'll surely blow things up fast. That is, the current kmod tests uses request_module() or get_fs_type(), you'd want a new test case with this added using then two new dummy test drivers with the macro dependency.
>>
>> If you want to resolve this using a more tested path, you could have request_module() be used as that is currently tested. Perhaps a test patch for that can rule out if it's the macro magic which is the issue.
>>
>> Luis
>>
>Maybe issue is related to a bug in introduction of symbol namespaces, see here:
>https://lkml.org/lkml/2019/10/11/659
If you're running into depmod and module loading issues with kernels >=5.3-rc1,
it's likely due to the namespaces patchset and we're working on
getting all the kinks fixed. Could you please ask the bug reporter to
try the latest -rc kernel with these set of fixes applied on top?
https://lore.kernel.org/linux-modules/20191010151443.7399-1-maennich@google.com/
They fix a known depmod issue caused by our __ksymtab naming scheme,
which is being reverted in favor of extracting the namespace from
__kstrtabns and __ksymtab_strings. These fixes will be in by -rc4.
Thanks,
Jessica
next prev parent reply other threads:[~2019-10-14 10:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-10 16:50 Module loading problem since 5.3 Heiner Kallweit
[not found] ` <CAB=NE6XdVXMnq7pgmXxv4Qicu7=xrtQC-b2sXAfVxiAq68NMKg@mail.gmail.com>
2019-10-11 19:26 ` Heiner Kallweit
2019-10-14 8:52 ` Luis Chamberlain
2019-10-14 14:44 ` Matthias Maennich
2019-10-16 12:50 ` Luis Chamberlain
2019-10-16 13:37 ` Matthias Maennich
2019-10-18 12:18 ` Luis Chamberlain
2019-10-23 10:49 ` Matthias Maennich
2019-10-23 12:35 ` Luis Chamberlain
2019-10-24 9:22 ` Matthias Maennich
2019-10-14 10:01 ` Jessica Yu [this message]
2019-10-14 10:32 ` Luis Chamberlain
2019-10-14 18:16 ` Heiner Kallweit
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=20191014100143.GA6525@linux-8ccs \
--to=jeyu@kernel.org \
--cc=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.