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@xxxxxxxxx <mailto:hkallweit1@xxxxxxxxx>> 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