From: Luis Chamberlain <mcgrof@kernel.org>
To: Heiner Kallweit <hkallweit1@gmail.com>,
Matthias Maennich <maennich@google.com>,
Jessica Yu <jeyu@kernel.org>
Cc: 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 08:52:35 +0000 [thread overview]
Message-ID: <20191014085235.GW16384@42.do-not-panic.com> (raw)
In-Reply-To: <875eecfb-618a-4989-3b9f-f8272b8d3746@gmail.com>
On Fri, Oct 11, 2019 at 09:26:05PM +0200, Heiner Kallweit wrote:
> 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
Can you have your user with issues either revert 8651ec01daed or apply the fixes
mentioned by Matthias to see if that was the issue?
Matthias what module did you run into which let you run into the issue
with depmod? I ask as I think it would be wise for us to add a test case
using lib/test_kmod.c and tools/testing/selftests/kmod/kmod.sh for the
regression you detected.
Luis
next prev parent reply other threads:[~2019-10-14 8:52 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 [this message]
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
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=20191014085235.GW16384@42.do-not-panic.com \
--to=mcgrof@kernel.org \
--cc=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=jeyu@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maennich@google.com \
--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 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).