Display loaded modules, their dependencies and parameter set

[apalakun]

No description provided.

[brenns10]

This will be a quite useful helper, thank you.

I do actually believe that this would be even better suited for contributing directly to drgn. While drgn already has a basic lsmod feature (see contrib/lsmod.py), helpers that can load module parameters would be nice to contribute upstream. We can talk about more after you've gone through the suggestions here.

[brenns10]

Not sure if you're ready for review yet: there are still some failures on the gitlab vmcore tests. Let me know when you're ready for another look!

[brenns10]

In the case of a LookupError, I think we can still print out the name, and indicate that we didn't know what to do with it. EG:

table_value.append([kp.name.string_().decode("utf-8"), kern_parm, "UNKNOWN", "UNKNOWN"])
continue

This way, module parameters are not skipped over just because we had trouble with them.

[brenns10]

Did you encounter page faults with integer types? I wouldn't expect that. If you're not working around a known issue, I'd prefer you not catch this error.

Regardless, with the continue statement here, the parameter will get skipped and won't be added to the list in the FaultError case. We should be including all parameters even on error. It would be best to remove the continue statement.

[apalakun]

Yes we have encountered and below is the localtest done on the vmcore
[apalakun@lse-india-drgn drgn-tools]$ python3 -m drgn_tools.corelens /drgn_vmcore/githubCI/rds-uek5/vmcore --debuginfo /drgn_vmcore/githubCI/rds-uek5/ -M lsmod > ~/4.txt
error: Encountered exception in lsmod:
Traceback (most recent call last):
File "/drgn_home/apalakun/github/drgn-tools/drgn_tools/corelens.py", line 340, in run_module
mod.run(prog, args)
File "/drgn_home/apalakun/github/drgn-tools/drgn_tools/lsmod.py", line 157, in run
print_module_parameters(prog)
File "/drgn_home/apalakun/github/drgn-tools/drgn_tools/lsmod.py", line 72, in print_module_parameters
parm_valf = parm_valf_address[0].value()
_drgn.FaultError: could not read memory from kdump: Cannot get page I/O address: Page not present: pte[477] = 0x0: 0xffffffffc05dd000

[brenns10]

That's wild, I guess it is also __initdata!

[brenns10]

I'm assuming that 40 is the size of struct kernel_param and you're adjusting the hex value to point to the next parameter?

This is contrary to the entire point of drgn: it knows the size of structures, and it can tell you the address of objects. Rather than maintaining your own variable, and hard-coding structure sizes, let's have drgn maintain everything for us.

Please delete the kpr_parm variable entirely. When you need the hex address of the struct kernel_param, you can do hex(kp.address_of_()).

[apalakun]

added string "array_length" to the output showing the length of the array

MODULE NAME: parport_pc
PARAM COUNT: 5
ADDRESS : 0xffffffffc0327390
PARAMETER ADDRESS TYPE VALUE
init_mode 0xffffffffc03268a0 charp (null)
dma 0xffffffffc03268c0 array array_length: 16
irq 0xffffffffc03268e0 array array_length: 16
io_hi 0xffffffffc0326900 array array_length: 17
io 0xffffffffc0326920 array array_length: 17

[brenns10]

Ok, I think the logic for the module parameter parsing all looks sound. However, I think the print_module_parameters() function needs to be broken down:

• It's got a ton of ifs, multiple loops, and several try/except statements, which make the nesting very deep, and the code more difficult to understand.
• It would be nice to add support for properly reading the array value out, but that would add even more code to an already large function.
• It seems like there should be a programmer's API that allows us to fetch the module parameter information, without printing it. As it is now, your only option is to print the parameters.

I pushed a commit to my own branch which modifies your implementation and addresses those issues, just to illustrate my point. I tried to simplify things as much as possible, and I split it out into three main functions:

1. decode_param() interprets a single kernel parameter and gets the drgn object for it, if possible
2. module_params() returns a dictionary of parameters for a single module (you can also use KernelModule.params())
3. print_module_parameters() is much smaller now, all it is responsible for is formatting the data

Here is my patch. We can just use that as-is, or if you want to incorporate the ideas yourself in your own way, that's great too. Just let me know.

[brenns10]

From email discussion, we'll merge this and apply my patch on top.