🔁 Quick Recap

In this series so far:

• Part 1: You understood what Kprobes are and why they matter
• Part 2: You applied Kprobes in real debugging scenarios

However, one important piece was still missing.

👉 You could observe function entry
👉 You could inspect arguments

But you still could not answer:

💭 Did the function succeed?
💭 What value did it return?
💭 How long did it take to execute?

Therefore, it’s time to complete the picture.

---

The Missing Link in Debugging

Kprobes give you visibility into what goes into a function. However, they do not reveal what comes out of it.

As a result, your debugging remains incomplete.

For example, you may confirm that a function was executed. Yet, you still cannot determine whether it failed or succeeded. In addition, performance issues remain hidden because execution time is unknown.

Therefore, to move from observation to understanding, you need Kretprobes.

---

🔍 What Are Kretprobes?

Kretprobes allow you to hook into the return path of a function. In other words, they trigger when the function is about to exit.

Because of this, you can:

✔ Capture return values
✔ Measure execution time
✔ Analyze success and failure paths

To simplify:

• Kprobe → Function Entry
• Kretprobe → Function Exit

Together, they provide a complete debugging view.

---

Use Case 1: Detecting Function Failures

Scenario

Sometimes, kernel functions fail silently. In such cases, logs may not clearly indicate the issue.

Therefore, relying only on entry tracing is not enough.

---

🧪 Code Example

#include <linux/module.h>
#include <linux/kprobes.h>

static struct kretprobe krp;

static int handler_ret(struct kretprobe_instance *ri, struct pt_regs *regs)
{
    long ret = regs_return_value(regs);

    if (ret < 0)
        pr_info("Function failed with error: %ld\n", ret);
    else
        pr_info("Function succeeded: %ld\n", ret);

    return 0;
}

static int __init kretprobe_init(void)
{
    krp.kp.symbol_name = "do_sys_open";
    krp.handler = handler_ret;
    krp.maxactive = 20;

    register_kretprobe(&krp);
    pr_info("Kretprobe registered\n");
    return 0;
}

static void __exit kretprobe_exit(void)
{
    unregister_kretprobe(&krp);
    pr_info("Kretprobe unregistered\n");
}

module_init(kretprobe_init);
module_exit(kretprobe_exit);
MODULE_LICENSE("GPL");

---

What This Solves

✔ Detect hidden failures
✔ Capture error codes
✔ Understand real outcomes

---

Use Case 2: Measuring Execution Time

Scenario

Performance issues are often difficult to diagnose. For instance, a function may execute correctly but still take too long.

Therefore, you need precise timing information.

---

🧪 Code Example

#include <linux/ktime.h>

struct my_data {
    ktime_t entry_time;
};

static int handler_entry(struct kretprobe_instance *ri, struct pt_regs *regs)
{
    struct my_data *data = (struct my_data *)ri->data;
    data->entry_time = ktime_get();
    return 0;
}

static int handler_ret(struct kretprobe_instance *ri, struct pt_regs *regs)
{
    struct my_data *data = (struct my_data *)ri->data;
    s64 delta;

    delta = ktime_to_ns(ktime_sub(ktime_get(), data->entry_time));
    pr_info("Execution time: %lld ns\n", delta);

    return 0;
}

static int __init kretprobe_init(void)
{
    krp.kp.symbol_name = "do_sys_open";
    krp.entry_handler = handler_entry;
    krp.handler = handler_ret;
    krp.data_size = sizeof(struct my_data);
    krp.maxactive = 20;

    register_kretprobe(&krp);
    return 0;
}

---

What This Solves

✔ Measure latency accurately
✔ Identify slow paths
✔ Debug performance bottlenecks

---

Use Case 3: Tracking Success vs Failure Ratio

Scenario

In real systems, failures are often intermittent. Therefore, observing a single instance is not sufficient.

Instead, you need aggregated insights over time.

---

🧪 Code Example

static int success = 0, failure = 0;

static int handler_ret(struct kretprobe_instance *ri, struct pt_regs *regs)
{
    long ret = regs_return_value(regs);

    if (ret < 0)
        failure++;
    else
        success++;

    pr_info("Success: %d | Failure: %d\n", success, failure);
    return 0;
}

---

What This Solves

✔ Identify instability patterns
✔ Analyze reliability
✔ Detect intermittent issues

---

⚠️ Important Considerations

Although Kretprobes are powerful, careful usage is essential.

• Keep handlers lightweight
• Avoid heavy processing inside probe handlers
• Tune maxactive properly
• Be cautious in production systems

---

Key Takeaway

So far, you have explored two dimensions of debugging.

First, Kprobes helped you understand what enters a function. Next, Kretprobes helped you understand what exits it.

Therefore, combining both provides complete visibility.

Ultimately, debugging becomes structured, predictable, and far more effective.

---

🔜 What’s Next?

Now that you understand:

✔ Function entry (Kprobes)
✔ Function exit (Kretprobes)

The next logical question is:

💭 What happens inside the kernel when a probe is hit?
💭 How does the kernel manage probes internally?

👉 In the next blog, we will dive into Kprobe internals inside the kernel.

---

Build Strong Debugging Foundations

Tools like Kprobes and Kretprobes are powerful. However, their true potential is unlocked only when you understand the system deeply.

If you want to build strong foundations in:

✔ Embedded Linux
✔ Kernel internals
✔ Device driver development
✔ Real-world debugging

Explore:

👉 https://embitude.in/embedded-linux-bundle/

🎥 Learn more on YouTube:
👉 https://www.youtube.com/@PradeepTewani

🤝 Join the community:
👉 https://embitudeinfotech.graphy.com/s/community