• Linus Torvalds's avatar
    Clarify naming of thread info/stack allocators · b235beea
    Linus Torvalds authored
    We've had the thread info allocated together with the thread stack for
    most architectures for a long time (since the thread_info was split off
    from the task struct), but that is about to change.
    
    But the patches that move the thread info to be off-stack (and a part of
    the task struct instead) made it clear how confused the allocator and
    freeing functions are.
    
    Because the common case was that we share an allocation with the thread
    stack and the thread_info, the two pointers were identical.  That
    identity then meant that we would have things like
    
    	ti = alloc_thread_info_node(tsk, node);
    	...
    	tsk->stack = ti;
    
    which certainly _worked_ (since stack and thread_info have the same
    value), but is rather confusing: why are we assigning a thread_info to
    the stack? And if we move the thread_info away, the "confusing" code
    just gets to be entirely bogus.
    
    So remove all this confusion, and make it clear that we are doing the
    stack allocation by renaming and clarifying the function names to be
    about the stack.  The fact that the thread_info then shares the
    allocation is an implementation detail, and not really about the
    allocation itself.
    
    This is a pure renaming and type fix: we pass in the same pointer, it's
    just that we clarify what the pointer means.
    
    The ia64 code that actually only has one single allocation (for all of
    task_struct, thread_info and kernel thread stack) now looks a bit odd,
    but since "tsk->stack" is actually not even used there, that oddity
    doesn't matter.  It would be a separate thing to clean that up, I
    intentionally left the ia64 changes as a pure brute-force renaming and
    type change.
    Acked-by: default avatarAndy Lutomirski <luto@amacapital.net>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    b235beea
Kconfig 19.3 KB