-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A slabinfo fix, and the v1 (1.1.0) release #103
Conversation
Freelist corruption results in the "slabinfo" module crashing. Since this is a common symptom of use-after-free bugs, we'd rather give useful information about this case. So don't crash the module. Catch the error and report corruption issues at the end. This also helps in certain cases where we are running against a live kernel, and the freelist is not corrupt, but it changed by the time we decoded the pointer. As a result, we print different messages at different times: for live systems, we say this may be transient, but for core dumps, we say it indicates a potential use-after-free bug. To do this, we have to implement a rather sketchy workaround to use the _SlabCacheHelperSlub from drgn. This is manually verified to work on 0.0.25 through 0.0.27, which are the only supported drgn versions. But, we need to work on upstream tweaks to improve the slab helpers, so we don't need to rely on the hack. Signed-off-by: Stephen Brennan <[email protected]>
buildrpm/python-drgn-tools.spec
Outdated
@@ -1,7 +1,7 @@ | |||
# Copyright (c) 2024, Oracle and/or its affiliates. | |||
# Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl/ | |||
Name: python-drgn-tools | |||
Version: 0.9.1 | |||
Version: 1.0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is the main branch, so it is still 1.0.0? You will create a new branch for v1 and set version to 1.1.0 there and also change the version here to 2.0.0, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I totally missed that. This should go to 1.1.0, I'll create the stable/v1
branch, and then on the main branch I'll bump to 2.0.0.
Signed-off-by: Stephen Brennan <[email protected]>
ed7dfd2
to
85e1b66
Compare
@@ -61,6 +61,9 @@ rm %{buildroot}/usr/bin/DRGN | |||
%{_mandir}/man1/corelens.1.gz | |||
|
|||
%changelog | |||
* Tue Aug 27 2024 Stephen Brennan <[email protected]> - 1.1.0-1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be 1.1.0 instead of 1.1.0-1?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, most RPMs have a release version appended with the hyphen, it starts at 1. If we update the packaging alone, we'll update that number.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It comes from line 5 above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
The slabinfo fix was more involved than I wanted, but it works well, is compatible with drgn 0.0.25 - 0.0.27, and it actually makes the
slabinfo
module modestly faster.