resolve_collision(9)

💅 resolve_collision(9) — like, the collision-resolving girlie of the kernel API manual ✨

okay so bestie, welcome to resolve_collision(9), straight out of the Kernel API Manual. grab a strawberry 🍓 and let's get into it.

---

🌸 NAME 🌸

resolve_collision — resolve a collision. that's it, that's the vibe. it resolves a collision, no cap.

---

✨ SYNOPSIS ✨

int resolve_collision (struct ubifs_info *c , const union ubifs_key *key
, struct ubifs_znode **zn , int *n , const struct fscrypt_name *nm );

look at her. five args, one int back. she's serving signature energy 💅

---

🎀 ARGUMENTS 🎀

• c — the UBIFS file-system description object. like, the whole filesystem's little personality profile 🦋
• key — key of a directory or extended attribute entry. it's giving "who are we even looking for" 🔍
• zn — znode is returned here. yes bestie, it's an out-param, she gets filled in 📥
• n — zbranch number is passed and returned here. in and out, she's versatile like that 😭
• nm — name of the entry. the actual name-name, the whole point of the search 🏷️

---

👑 DESCRIPTION 👑

so here's the tea. this function gets called for "hashed" keys — the ones that got hashed — and its whole job is making sure that the key we found actually corresponds to the node we looked up (a directory or extended attribute entry). like, vibe check the match, fr fr. 🔥

here's the receipt on what she returns:

1. 1 — the collision is resolved! slay. she sets zn and n for you 🫶
2. 0 — nm was not found. and get this: zn and n get set to the previous entry, i.e. to the entry after which nm could follow if it were in TNC. so heads up — this means n may be set to -1 if the leftmost key in zn is the previous one. lowkey unhinged but it's what she does 💀
3. negative error code — returned on failures. sad girl hours 😭

no cap, that -1 case is real and you should not be surprised by it. the leftmost key in zn being the previous one will do that to a n.

---

🦋 SEE ALSO 🦋

she runs with a whole friend group, all from the kernel file ./fs/ubifs/tnc.c. like, literally all of these:

• insert_old_idx(9)
• insert_old_idx_znode(9)
• ins_clr_old_idx_znode(9)
• destroy_old_idx(9)
• copy_znode(9)
• add_idx_dirt(9)
• replace_znode(9)
• dirty_cow_znode(9)
• lnc_add(9)
• lnc_free(9)
• tnc_read_hashed_node(9)
• try_read_node(9)
• fallible_read_node(9)
• matches_name(9)
• get_znode(9)
• tnc_next(9)
• tnc_prev(9)
• fallible_matches_name(9)
• fallible_resolve_collision(9)
• matches_position(9)
• resolve_collision_directly(9)
• dirty_cow_bottom_up(9)
• ubifs_lookup_level0(9)
• lookup_level0_dirty(9)
• maybe_leb_gced(9)
• ubifs_tnc_locate(9)
• ubifs_tnc_get_bu_keys(9)
• read_wbuf(9)
• validate_data_node(9)
• ubifs_tnc_bulk_read(9)
• do_lookup_nm(9)
• ubifs_tnc_lookup_nm(9)
• ubifs_tnc_lookup_dh(9)
• correct_parent_keys(9)
• insert_zbranch(9)
• tnc_insert(9)
• ubifs_tnc_add(9)
• ubifs_tnc_replace(9)
• ubifs_tnc_add_nm(9)
• tnc_delete(9)
• ubifs_tnc_remove(9)
• ubifs_tnc_remove_nm(9)
• ubifs_tnc_remove_dh(9)
• key_in_range(9)
• ubifs_tnc_remove_range(9)
• ubifs_tnc_remove_ino(9)
• ubifs_tnc_next_ent(9)
• tnc_destroy_cnext(9)
• ubifs_tnc_close(9)
• left_znode(9)
• right_znode(9)
• lookup_znode(9)
• is_idx_node_in_tnc(9)
• is_leaf_node_in_tnc(9)
• ubifs_tnc_has_node(9)
• ubifs_dirty_idx_node(9)
• dbg_check_inode_size(9)

go read them. iykyk 📚

---

and that's the page, bestie 🧚 this one shipped from ./fs/ubifs, dated October 2026, and yes — the manual tag resolve_collision(9) belongs to her, periodt. mwah 💋🎀