Feature #9394
openSupport verification of built-in Linux kernel modules
Added by Evgeny Novikov over 5 years ago. Updated about 3 years ago.
0%
Description
Some time ago Klever could verify built-in Linux kernel modules like loadable ones pretty well. But in Klever 2.0 this was broken.
Updated by Evgeny Novikov almost 5 years ago
- Priority changed from Urgent to High
- Target version deleted (
3.0)
Linux is not our main priority.
Updated by Evgeny Novikov about 3 years ago
- Priority changed from High to Urgent
- Target version set to 3.1
Seems that users suffer from this issue more and more.
Updated by Ilja Zakharov about 3 years ago
- Status changed from New to Resolved
Implemented in pfg-internal-modules.
Updated by Evgeny Novikov about 3 years ago
- Status changed from Resolved to Open
Pavel detected the following exception:
Raise exception:
Traceback (most recent call last):
File "/home/alpha/git/klever/venv/lib/python3.7/site-packages/klever/core/components.py", line 395, in run
self.main()
File "/home/alpha/git/klever/venv/lib/python3.7/site-packages/klever/core/components.py", line 304, in callbacks_caller
ret = attr(*args, **kwargs)
File "/home/alpha/git/klever/venv/lib/python3.7/site-packages/klever/core/pfg/__init__.py", line 49, in generate_program_fragments
attr_data, pairs = strategy.fragmentation(fset, tactic_name, fset_name)
File "/home/alpha/git/klever/venv/lib/python3.7/site-packages/klever/core/pfg/fragmentation/__init__.py", line 85, in fragmentation
self.tactic.get("ignore missing files"))
File "/home/alpha/git/klever/venv/lib/python3.7/site-packages/klever/core/pfg/abstractions/__init__.py", line 44, in init
self.__divide(skip_missing_files)
File "/home/alpha/git/klever/venv/lib/python3.7/site-packages/klever/core/pfg/abstractions/__init__.py", line 424, in __divide
raise RuntimeError(msg)
RuntimeError: Cannot calculate path to existing file '/home/alpha/git/linux/scripts/dtc/dtc-lexer.lex.c'
Updated by Evgeny Novikov about 3 years ago
- Status changed from Open to Closed
Ilja fixed it so that no extra information is necessary to consider built-in modules absolutely like loadable ones. The branch passed tests. Moreover, I added one more preset job for testing built-in modules support. That job is a complete copy of "Loadable kernel modules sample" except for a kernel configuration ("allyesconfig" rather than "allmodconfig").
Updated by Evgeny Novikov about 3 years ago
I merged the branch to master in 3f7db52cf. Everybody is welcome to cherry-pick commits 753efebd13e90ab12fe4c623509da7062bc7904f and 4d4197b319d5e553cb6dc774d34cd114a9afc454 to support built-in modules.
Updated by Ilja Zakharov about 3 years ago
Built-in modules are selected by iterating all CC commands collected by Clade. Commands from modules have either a 'KBUILD_MODNAME' or '-DKBUILD_MODNAME' option. Klever groups input files of commands with the same value of the mentioned options to get modules even if there are linked to the kernel. This approach is used for fragmentation strategy "statically linked modules". By default, Klever is using the approach with iterating over LD commands to detect modules.
Updated by Evgeny Novikov about 3 years ago
- Status changed from Closed to Open
- Priority changed from Urgent to High
It was my mistake that I merged the branch to master too early while it turned out that it is not so vital. Indeed, we need to investigate the issue better and to fix different corner cases. The current implementation is still in branch pfg-internal-modules that I hope to be completed for Klever 3.1. I reverted corresponding commits in master.
Updated by Evgeny Novikov about 3 years ago
- Target version changed from 3.1 to 3.2
We need to release Klever 3.1 faster due to an incompatibility with Clade 3.3+ and a new OpenStack cloud.
Updated by Evgeny Novikov about 3 years ago
- Target version deleted (
3.2)
I am not sure that current users of Klever suffer from this issue. Let's wait till somebody will complain.
Updated by Evgeny Novikov about 3 years ago
Though, the suggested solution does help to consider built-in modules like loadable, it has several drawbacks:
- I noticed that it also considers source files of the kernel as program fragments.
- Names of some modules differ with the ones when the default strategy is used. For instance, "-"s are replaced with "_" and this does not depend on whether modules are built-in or loadable for a given configuration. Perhaps, other changes also exist. This is bad since program fragment names are used for associating marks and for comparing verification results.
- I am not sure that all built-in modules are revealed properly as well as that loadable modules are not missed. Some experiments are really necessary to get more confidence.
Anyway, I think that another way should be used to verify built-in modules. Maybe the way we used before switching to Clade can help or something new should be suggested.