STRUCT COND_SNAPSHOT(9)

💅 struct cond_snapshot — the Kernel API Manual tea 🎀

okay bestie so this is the page for struct cond_snapshot(9), straight out of the kernel API manual, and it's genuinely iconic once you get the vibe. it's all about conditional snapshots — like a snapshot but with ✨standards✨. let's get into it.

---

🌸 SYNOPSIS 🌸

here's the whole struct, and honestly? it's giving minimal main character energy — only two members:

struct cond_snapshot {
    void *cond_data;
    cond_update_fn_t update;
 };

---

🦋 Members 🦋

• update — okay so when a conditional snapshot gets invoked, this callback function is invoked with tr->max_lock held 🔒. the update implementation gets to call the shots — it signals whether or not to actually take the snapshot by returning 'true' if yes bestie, 'false' if no snapshot should be taken 🙅. and the reason it's safe to be that direct is because max_lock is held for the entire duration of update, so the implementation can go ahead and directly retrieve and save any implementation data it needs to, right there in association with the snapshot. no cap, it's fully safe 💖.

---

✨ Description ✨

so what is this thing? the cond_snapshot structure encapsulates a callback function and the data associated with the snapshot for a given tracing instance 🫶.

when a snapshot is taken conditionally — which you do by invoking tracing_snapshot_cond(tr, cond_data) — the cond_data you pass in gets passed in turn to the cond_snapshot.update function 🔁. the update implementation can then compare that data with the cond_data contained within the struct cond_snapshot instance associated with the trace_array. and because tr->max_lock is held throughout the whole update call, the update function can directly retrieve the cond_snapshot and cond_data associated with the per-instance snapshot associated with the trace_array 🔥. no awkward locking dance, it's just right there.

the cond_snapshot.update implementation can save data to be associated with the snapshot if it decides to — and it returns 'true' in that case — or it returns 'false' if the conditional snapshot shouldn't be taken 💅.

and how does this thing even come into existence? the cond_snapshot instance is created and associated with the user-defined cond_data by tracing_cond_snapshot_enable ⭐. likewise, the cond_snapshot instance is destroyed and is no longer associated with the trace instance by tracing_cond_snapshot_disable 💀. creation and destruction, enable and disable, the full lifecycle, we love to see it.

the method below is required. like, not optional, not "if you feel like it" — required. periodt 👑

---

👀 SEE ALSO 👀

• Kernel file ./kernel/trace/trace.h struct tracer(9)
• tracer_tracing_is_on_cpu(9)
• event_trigger_unlock_commit(9)
• struct event_command(9)
• enum event_command_flags(9)

---

okay that's the whole page, bestie, you ate that 🍓💜. this little beauty lives in ./kernel/trace and the manual dates it to October 2026 — so go forth, take your conditional snapshots, and remember: update returns 'true' or 'false', and the lock is always held 🌈✨🦋