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 <hkallwe...@gmail.com > > <mailto:hkallwe...@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
