prb_reserve_in_last(9)

💅 prb_reserve_in_last — a.k.a. the "bestie can i have more space pls" function

okay so this one lives in the Kernel API Manual, and it's genuinely such a serve once you get it. the whole vibe: you already wrote a record, and now you're like "wait i need MORE room" and this is the function that goes back and re-reserves + extends the space in the ringbuffer that the newest record is using. iconic behavior honestly. 🎀

---

✨ NAME ✨

prb_reserve_in_last — re-reserve and extend the space in the ringbuffer used by the newest record.

---

🦋 SYNOPSIS 🦋

bool prb_reserve_in_last (struct prb_reserved_entry *e , struct
       printk_ringbuffer *rb , struct printk_record *r , u32 caller_id ,
       unsigned int max_size );

---

🌸 ARGUMENTS 🌸

• e — the entry structure you're setting up. she's the one holding the receipts ✨
• rb — the ringbuffer where you're re-reserving and extending data. the venue, if you will 💅
• r — the record structure you're allocating buffers for. the main character 🎀
• caller_id — the caller ID of the caller (that's the reserving writer, aka you). gotta prove it's really you 🫶
• max_size — if the extended size would end up greater than this, the whole thing fails. a hard limit, no cap 💀

---

💖 DESCRIPTION 💖

this is the public function that writers get to use for re-reserving and extending data. like, it's literally for you.

so here's the deal bestie: you tell it the text size to extend — NOT the new total size — by setting the text_buf_size field of r. and to make sure r is initialized properly (like, actually properly, not the way you "initialized" your sleep schedule), you should use prb_rec_init_wr.

this function will fail if caller_id doesn't match the caller ID of the newest record. rude? maybe. correct? absolutely. in that case the caller must reserve new data using prb_reserve. no cheating around it.

on success, the whole situation is:

• r->text_buf points to the beginning of the entire text buffer. beginning, bestie, the beginning.
• r->text_buf_size is set to the new total size of the buffer. slay.
• r->info is not touched, so that r->info->text_len could be used to append the text. untouched and thriving.
• prb_record_text_space can be used on e to query the new actually used space. the truth-teller of the group chat.

Important: all r->info fields will already be set with the current values for the record. i.e. r->info->text_len will be less than text_buf_size. writers can use r->info->text_len to know where concatenation begins, and writers should update r->info->text_len after concatenating. do not skip that last part. i'm serious. 😭

---

👑 CONTEXT 👑

any context. disables local interrupts on success — so like, when she succeeds she takes over for a sec. respect it. 💅

---

🔥 RETURN 🔥

true if text data could be extended, otherwise false. that's it. that's the tea. 🍓

---

🌈 SEE ALSO 🌈

• kernel file ./kernel/printk/printk_ringbuffer.c
• printk_ringbuffer overview(9)
• prb_reserve(9)
• prb_commit(9)
• prb_final_commit(9)
• prb_next_reserve_seq(9)
• prb_read_valid(9)
• prb_read_valid_info(9)
• prb_first_valid_seq(9)
• prb_next_seq(9)
• prb_init(9)
• prb_record_text_space(9)

---

kk that's the whole page bestie, go forth and extend your ringbuffer with confidence 💜

sign-off: brought to you by ./kernel/printk, dated October 2026 — same page, same facts, just way cuter. mwah 🧚✨