-
Notifications
You must be signed in to change notification settings - Fork 451
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
Linux adds hlist_head object extension #1314
Linux adds hlist_head object extension #1314
Conversation
I think the idea was, that you couldn't ask the module for a fully qualified name, because it should only be returning objects that belong to the module. There should be an additional check that allows |
Seems an awfully strange doubly-linked list, if the links go in crazy directions, but ok, thanks for the heads-up! 5:P |
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.
Just want to check where member_name
comes from but otherwise looks ok?
@@ -245,7 +245,7 @@ def object( | |||
""" | |||
if constants.BANG not in object_type: | |||
object_type = self.symbol_table_name + constants.BANG + object_type | |||
else: | |||
elif not object_type.startswith(self.symbol_table_name + constants.BANG): |
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.
Yep, this is probably what it should always have been, sorry I didn't include it first time round!
current = current.next | ||
|
||
def __iter__(self) -> Iterator[interfaces.objects.ObjectInterface]: | ||
return self.to_list(self.vol.parent.vol.type_name, self.vol.member_name) |
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.
Is member_name
defined as part of the type when an hlist_head
is constructed? I'm just interested to know what populates this value and what happens if it's not present? This feels a little brittle at the moment...
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.
Unfortunately, it's not. See the contructors here: https://elixir.bootlin.com/linux/v6.11.4/source/include/linux/list.h#L939.
The type is based on the destination variable type in the foreach preprocessor macros here: https://elixir.bootlin.com/linux/v6.11.4/source/include/linux/list.h#L1162
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.
Sooooo, how then does it get into the object's vol
dict? 5:)
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.
oh, sorry, I thought you were talking the struct in the kernel.
Yes, you are right.. good catch! I removed this object's ability to be directly iterable. It needs to be called via to_list()
to provide the correct member_name.
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.
hm I think the same happens with the list_head
objects. It requires to explicitly set a member_name
, not sure if it's used directly as an iterator somewhere, maybe that's why it never failed.
Hehe, yeah it's an "optimization" to save one pointer in the head... quite a fine-tuned detail, right? :) ... see this comment here: In the following sentence they make it clear it's not circular (apart from that they don't mention it).
On the other hand, see the description of a circular doubly linked list (list_head): |
…e it can't determine the correct member_name
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.
Ok, looks good, thanks! 5:)
The primary goal of this PR is to fix issue #1313 for kernels version 6.8 and above. However, to achieve this, two additional fixes are also required.
Module.object() fix
Additionally, this PR includes a fix for
Module.object()
which doesn't allow to create an object even if the symbol type name is from the same symbol table, see here. That makeslinux.LinuxUtilities.container_of()
to fail when it's called from some places. Additionally, it's inconsistent with other functions that allow the use of the same symbol name even when they are called from the same object.So,
Module.object()
only works if it's called with only the symbol name i.e.dentry
and it creates the full names here:But if it's already called with the full symbol name, it fails:
On the other hand, the exception message doesn’t seem to accurately reflect what it’s checking. It talks about "module" when it's checking the symbol table name. Is this correct @ikelos?
hlist_head object extension
This PR adds a
hlist_head
object extension that other Linux plugins can benefit from. This resolves issue #1313.Please, read my comment here:
Please avoid adding a
forward
orsentinel
arguments! This list is not designed to be traversed in reverse order. Finding the tail requires O(n).