• Oleg Nesterov's avatar
    introduce __next_thread(), fix next_tid() vs exec() race · 33a98138
    Oleg Nesterov authored
    Patch series "introduce __next_thread(), change next_thread()".
    
    After commit dce8f8ed ("document while_each_thread(), change
    first_tid() to use for_each_thread()") + this series
    
    1. We have only one lockless user of next_thread(), task_group_seq_get_next().
       I think it should be changed too.
    
    2. We have only one user of task_struct->thread_group, thread_group_empty().
       The next patches will change thread_group_empty() and kill ->thread_group.
    
    
    This patch (of 2):
    
    next_tid(start) does:
    
    	rcu_read_lock();
    	if (pid_alive(start)) {
    		pos = next_thread(start);
    		if (thread_group_leader(pos))
    			pos = NULL;
    		else
    			get_task_struct(pos);
    
    it should return pos = NULL when next_thread() wraps to the 1st thread
    in the thread group, group leader, and the thread_group_leader() check
    tries to detect this case.
    
    But this can race with exec. To simplify, suppose we have a main thread
    M and a single sub-thread T, next_tid(T) should return NULL.
    
    Now suppose that T execs. If next_tid(T) is called after T changes the
    leadership and before it does release_task() which removes the old leader
    from list, then next_thread() returns M and thread_group_leader(M) = F.
    
    Lockless use of next_thread() should be avoided. After this change only
    task_group_seq_get_next() does this, and I believe it should be changed
    as well.
    
    Link: https://lkml.kernel.org/r/20230824143112.GA31208@redhat.com
    Link: https://lkml.kernel.org/r/20230824143142.GA31222@redhat.comSigned-off-by: default avatarOleg Nesterov <oleg@redhat.com>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    33a98138
base.c 93.9 KB