lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191014085235.GW16384@42.do-not-panic.com>
Date:   Mon, 14 Oct 2019 08:52:35 +0000
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Heiner Kallweit <hkallweit1@...il.com>,
        Matthias Maennich <maennich@...gle.com>,
        Jessica Yu <jeyu@...nel.org>
Cc:     linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: Module loading problem since 5.3

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@...il.com <mailto:hkallweit1@...il.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ