Messages in this thread | | | From | Valentin Schneider <> | Subject | Re: Question about a8ea6fc9b089 ("sched: Stop PF_NO_SETAFFINITY from being inherited by various init system threads") | Date | Fri, 11 Jun 2021 15:19:29 +0100 |
| |
On 11/06/21 06:52, Paul E. McKenney wrote: > On Fri, Jun 11, 2021 at 11:12:29AM +0100, Valentin Schneider wrote: >> >> The way I see 570a752b7a9b is that, if a task is pinned to a single CPU but >> doesn't have PF_NO_SETAFFINITY, then userspace can unpin it. This means it >> ought to have entered check_preemption_disabled() with preemption disabled >> - right now it may be pinned, but that can change at any minute, and >> whatever code it is running needs to cope with that. > > Thank you for catching me up on this topic! > >> Could you share some details on which tasks you are hitting this with? > > Let's start with ref_scale_reader() in kernel/rcu/refscale.c. This > is for fine-grained in-kernel benchmarking, so it really wants kthreads > running this function to be pinned. > > I took a look at kthread_bind(), but it is not intended to be called by > the kthread itself. Looking elsewhere in the kernel, it looks like I > just do this right after invoking set_cpus_allowed_ptr(): > > current->flags != PF_NO_SETAFFINITY; > > Or am I missing a better way to handle this?
Looking at ref_scale_reader(), ISTM the initial configuration (affinity, niceness) should be done by its parent thread, not by itself. i.e.:
p = kthread_create(ref_scale_reader); kthread_bind(p, cpu); // Does the pinning + sets PF_NO_SETAFFINITY set_user_nice(p, MAX_NICE); wake_up_process(p);
(kthread_create_on_cpu() is also an option)
From what I can see, torture_create_kthread() immediately wakes the newly-created kthread, we'd need a version that calls kthread_create() instead of kthread_run() for the above. Would that be an issue?
> > Thanx, Paul
| |