Minor bug fixes and improvements before the release.#216
Merged
Conversation
Orabug: 39523319 Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
oracle-contributor-agreement
Bot
added
the
OCA Verified
imran-kn
reviewed
Jun 9, 2026
Using "nr_cpu_ids" is incorrect, this gives the number of present CPUs, but not the number of online ones. Sum the online CPU mask instead. This is easily reproduced by specifying maxcpus=N for some N higher than the smp CPU count in QEMU. Do this so we can reproduce the issue and add a regression test. Adding maxcpus=4 to the QEMU configuration exposed a bug in the workqueue tests: there are per-cpu pwqs for each *possible* CPU, not just each *online* CPU. No functional error since the bug was in the test, but good to catch it. Orabug: 38829413 Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
Crash shows the current task in the runq output. We filter it out, but it seems reasonable to leave it in and let the reader determine why it is there. Orabug: 38933146 Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
To iterate over each nvme disk, we were simply yielding each disk whose name started with "nvme". However, some of these disks' private_data may point at an nvme_ns_head, which the the nvme corelens module, and the inflight-io module, are not prepared to handle. To prevent this, use the "fops" field to actually check which kind of disk it is. This requires some compatibility checks for older kernels, but it's more robust. Orabug: 38995392 Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
This emulated disk will serve as test data for the NVME helpers. It would reproduce the crash/failure seen in the below bug, which was fixed in the prior commit. It also triggered some test failures for blockinfo, because hidden NVME disks don't have a major/minor disk exposed to userspace. Orabug: 38995392 Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
This adds a bit of weight to the rootfs, but it allows users to install packages by running dnf in the chroot. (The VM does not have internet access, yet). Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
Prior to about November of 2025, ksplice cold-patches could not be distinguished from their in-tree counterparts. Now, the cold-patches have a ".note.ksplice" section! This can be detected at runtime, so we can avoid even trying (and failing) to load a debuginfo file for them. Plus, it allows us to more accurately classify the modules that are loaded. Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
The debuginfo options have a toggle allowing you to disable extraction, so this can be configured, but the CLI and corelens set defaults without consulting the config. This is so that the CLI & corelens have consistent behavior. However, it turns out that unconditionally extracting debuginfo is an issue in some rare cases where modules (falcon...) falsely declare that they are in-tree, causing us to believe we should find debuginfo in our debuginfo RPM. This triggers costly extraction which is guaranteed to fail. Since there will likely be future issues like this, it's good to have a safety valve. This is not documented in the corelens args as we don't want customers relying on these various toggles: just like the -g option. Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
The OOT_MODULE is set in the modinfo and may be (accidentally) spoofed. We see this with some monitoring tools that customers install. It's not likely to be malicious intent, because they still mark themselves as having proprietary licenses. Use the PROPRIETARY_MODULE as an additional signal that a module is not in tree, so we don't try to extract such modules' debuginfo from the debuginfo RPM. This is the case that triggered the "-E" change in the previous commit. Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
Core dumps generated by hypervisors and other unusual scenarios can be missing critical metadata, preventing drgn from opening them. Usually we can repair them but we need to be able to pass in the vmcoreinfo and platform options to the Program constructor. Add two flags to do this in corelens: one which takes vmcoreinfo and automatically sets it (and the architecture if detected), and another which takes architecture. This mirrors drgn's CLI flags, though the --vmcoreinfo flag is a bit more helpful in drgn-tools. It would be better to do everything automatically, but it's not really possible to guarantee that random "VMCOREINFO-looking" blob of memory in a core dump is actually the correct note to decode the dump. Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This is a bit of a grab-bag of new features and fixes:
%corelenscommand for drgndnfpackage (and yum repositories) in the rootfs.The live test cases should be passing at this point. I'll need to audit the vmcore test suite to ensure it's still passing. After that, I'll create the PR with packaging changes and the release.