svn commit: r326218 - head/sys/kern

[Konstantin Belousov]

On Wed, Nov 29, 2017 at 04:33:50PM +0100, Hans Petter Selasky wrote:
> Hi Nathan,
> 
> The chunk below causes sched_pin() to stop working and should be removed 
> from your commit ??!!
> 
> It probably explains the hangs seen recently reported by various brave 
> people running 12-current :-)
> 
> Specifically I see threads migrating between CPUs when td->td_pinned > 0 
> using the LinuxKPI RCU API, which in turn leads to a hang when trying to 
> synchronize RCU.
> 
> --HPS
> 
> diff --git a/sys/kern/sched_ule.c b/sys/kern/sched_ule.c
> index 5c8bae5afa1..bd4b505f6c3 100644
> --- a/sys/kern/sched_ule.c
> +++ b/sys/kern/sched_ule.c
> @@ -2453,7 +2453,7 @@ sched_add(struct thread *td, int flags)
>           * Pick the destination cpu and if it isn't ours transfer to the
>           * target cpu.
>           */
> -       td_get_sched(td)->ts_cpu = curcpu; /* Pick something valid to 
> start */
> +//     td_get_sched(td)->ts_cpu = curcpu; /* Pick something valid to 
> start */
>          cpu = sched_pickcpu(td, flags);
>          tdq = sched_setcpu(td, cpu, flags);
>          tdq_add(tdq, td, flags);

To clarify.  It seems that this change breaks sched_bind().

It might be that LinuxKPI does use sched_pin() in somewhat questionable
way. Namely, the code puts the thread off the CPU (e.g. by taking a
lock). Then, is it guaranteed that the pinned thread returns to the same
cpu after sched_add() ?

I think that the second behaviour is not guaranteed, but it might
happens by the way the things are arranged. If guaranteed, then the
sched_pin() breakage is same as for sched_bind().