mesh_path_flush_by_nexthop(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… mesh_path_flush_by_nexthop(9)

okay so bestie, welcome to the Kernel API Manual entry for mesh_path_flush_by_nexthop(9) β€” yes that's the whole name, yes it's a mouthful, no we're not shortening it, it's iconic as is πŸŽ€


✨ NAME ✨

mesh_path_flush_by_nexthop β€” Deletes mesh paths if their next hop matches πŸ§ΉπŸ¦‹

like, it goes through and yeets the mesh paths whose next hop is the one you point at. that's the whole vibe.


🌸 SYNOPSIS 🌸

void mesh_path_flush_by_nexthop (struct sta_info *sta );

no return value, it's a void girly, she does the work and leaves πŸ’…


🫢 ARGUMENTS 🫢

  • sta β€” mesh peer to match. that's it, that's the whole argument. you hand her a mesh peer and she matches against it, slay.

πŸ’– DESCRIPTION πŸ’–

okay so the RCU notes, because this part is important and I need you to actually read it, bestie πŸ™ˆ

this function is called when a mesh plink transitions from PLINK_ESTAB to any other state β€” and the reason is lowkey genius: PLINK_ESTAB state is the only one that allows path creation. so the moment you leave that state, the paths gotta go.

and this all happens before the sta can be freed β€” because sta_info_destroy calls this β€” which means any reader sitting in an rcu read block will be protected against the plink disappearing. no cap, that's the safety guarantee, and it's giving main character energy πŸ”₯

ngl the ordering here is the whole point β€” flush happens first, free happens after, readers stay protected. don't mess with the sequence, fr fr.

🌈 SEE ALSO 🌈

Kernel file ./net/mac80211/mesh_pathtbl.c β€” and the whole friend group:


and that's the page!! πŸŽ€ this one lives in ./net/mac80211, dated October 2026, and it's filed under mesh_path_flush_by_nexthop(9) forever and ever. go forth and flush responsibly, bestie πŸ’œβœ¨

πŸ“¦ where this page comes from