An intrusive list embeds the link pointer(s) inside the data structure being stored, rather than wrapping the data in a separate node that contains a pointer to it. So a Task struct has its own Task *next (and maybe prev) member, and you link Tasks directly. The advantages that make it dominant in RTOSes and the Linux kernel: no separate node allocation, the object is the node, so there's nothing extra to malloc or pool, eliminating a whole class of allocation and node/data lifetime-mismatch bugs; an object can be on multiple lists at once by carrying multiple link members (a buffer on both a free list and a hash bucket); and it's cache-friendlier since the link sits with the data you're already touching. The tradeoff is the data type must be modified to carry the links (it's coupled to being list-able), and generic container reuse is harder than with a non-intrusive node-wrapping list, but in systems code, where you control the types and avoid allocation, intrusive lists win decisively.
Data Structures & Algorithms · Interview question
What's an intrusive linked list and why is it favored in embedded/kernel code?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
Linked Lists
Nodes chained by pointers: O(1) splice anywhere, O(n) search and no random access, and how embedded does them without a heap via static node pools and intrusive lists.