euspectre
commented
9 years ago Comment #1 originally posted by euspectre on 2012-02-23T17:45:00.000Z:
A tool to track allocation/deallocation of sk_buff structures is a very useful one indeed. I think many users could benefit from it, so if you share the code, it would be great.
As for the problem, KEDR itself currently has no way to recognize that an object was allocated/freed by another module or by the kernel proper. We also faced this problem in our projects.
Two ideas:
- Would it be OK for your tool if KEDR could track several kernel modules as a single entity? That is, if it could replace the calls in more than one module with the calls to your functions? This way, you could track allocation/deallocation of sk_buff structures both in the module you actually debug and in the underlying network driver as if they were a single module.
This feature is already in our TODO list but it may take some time to implement it.
- A colleague of mine and the co-author if KEDR, Andrey Tsyvarev has developed a system to track callback operations in the kernel modules, KEDR-COI: http://code.google.com/p/kedr-callback-operations-interception/ So far, we have used it to track file operations, inode operations and the like. But it also provides the means to prepare the components to track other types of callbacks.
The idea of that system is to intercept the calls to the functions that have registered the objects with callbacks of interest and to replace the callbacks in these objects.
Using KEDR-COI and KEDR at the same time, you could probably intercept the callback in the module under analysis that receives that newly created sk_buff instance and track that instance thereafter.
KEDR-COI is still experimental but it can be useful. The documentation for KEDR-COI is available in its package, see sources/doc/html/.
Original issue 4 created by euspectre on 2012-02-22T14:53:35.000Z:
Hello,
I'd like KEDR to track sk_buff alloc/free. I wrote some basic code to track __alloc_skb, skb_clone and kfree_skb. It's not perfect because it only tracks struct sk_buff allocation/free, not the data buffer it points to, but that doesn't matter for me here.
Now here's my problem:
The sk_buff is allocated by me on the send side and given to the network. It's basically free'd by the network driver after send (outside of the module I am debugging). On the receive side, the incoming sk_buff is allocated by the driver before giving it to me, and I take care of freeing it.
I worked around the send side problem by declaring that dev_queue_xmit() takes care of freeing my sk_buff. The freeing doesn't occur in dev_queue_xmit() for real, but that's where my module last sees its outgoing sk_buff, so that's fine.
On the receive side, it's harder. If the Linux receive model was my module calling a core/driver function to get the next incoming sk_buff, I would just tell KEDR that this function allocates the sk_buff. But the Linux model is the opposite: the core/driver calls a callback in my module with the incoming skb as a parameter.
So I basically need a way to tell KEDR "the skb passed to my module here has been allocated earlier, now please track it". How can I do that?
Brice Goglin
PS: Yeah, I'll share my code if you're interested