Merge remote-tracking branch '6.0/stage' into 'master' #48
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Omar Sandoval <osandov@osandov.com>
…ternal() If drgn_object_set_buffer_from_internal() (used to implement drgn_object_set_from_buffer(), drgn_object_slice(), and drgn_object_reinterpret()) sets an object to a primitive type from a buffer that comes from the same object, then drgn_object_reinit() will free the value and then drgn_value_serialize() will access the freed value, probably resulting in garbage. Handle this case the same way we do if the result type is encoded as a buffer, by first copying to a temporary value. This doesn't affect usage through Python because objects are immutable in the Python bindings. Signed-off-by: Omar Sandoval <osandov@osandov.com>
An upcoming fix requires us to always use the module list from the core dump rather than /proc/modules. However, with the existing code, this would cause a major startup time regression for the live kernel, mainly because reading from /proc/kcore is stupidly slow. We currently do 3 + strlen(module->name) reads for every module. We can reduce this to 1 read per module by reading the entire struct module at once. The size of struct module is ~700-900 bytes depending on the kernel configuration, which is still much faster to read than only reading what we need. In some benchmarks that I did with DRGN_USE_PROC_AND_SYS_MODULES=0, this reduced the time spent in the kernel module iterator from ~2.5ms per module to ~0.4ms per module. Signed-off-by: Omar Sandoval <osandov@osandov.com>
For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
The .data..percpu section is excluded from /sys/module and struct module::sect_attrs, which means that we default its address to 0. This results in global per-CPU variables in kernel modules being relocated starting from 0 rather than the offset of the per-CPU allocation made for the module, which in turn causes those variables to appear to contain the wrong data. Fix it by manually getting the per-CPU address from struct module. Closes osandov#185. Signed-off-by: Omar Sandoval <osandov@osandov.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.