Prior to the Linux 2.6 kernel, struct task_struct was present at the end of the kernel stack of each process. There was no thread_info struct concept. But in Linux 2.6 kernel, instead of task_struct being placed at the end of the kernel stack for the process, the thread_info struct is placed at the end. This thread_info struct contains a pointer to the task_struct structure.

What was the need for thread_info structure to be introduced ?. We could have accessed the task_struct structure using the stack pointer directly if task_struct was placed at the end of the kernel stack of the process.

In 2.6 Kernel, task_struct is dynamically allocated using slab_allocator. Prior to 2.6 Kernel, was it statically allocated?

2 Answers
2

I am not sure why this was done. But it'd be easy to find it out if you do a git blame on that file and find the commit that introduced the change. Usually commit message will have very detailed explanation of the change being committed.

The reason why we need the thread_info is due to the fact that we are allocating the memory for task_struct using the Slab Allocator. Now you may ask what is the relation between these?

To understand that you need to understand how Slab Allocator works.

Without the Slab Allocator , the kernel developers could allocate memory for task_struct in the kernel stack for the particular process so that it can be accessed easily. Now with the advent of Slab Allocator , the memory is allocated to the task_struct as determined by the Slab Allocator. So with the Slab Allocator you have task_struct stored somewhere else and not in the kernel stack of the particular process. Now the Kernel developers introduced thread_info and placed a pointer in it to the place where the task_struct resides. Thus we have thread_info in process's kernel stack instead of task_struct. And that is why we have to live with thread_info.

You can read about Slab Allocator in Robert Love's book Linux Kernel Development.