svn commit: r326218 - head/sys/kern

[Hartmann, O.]

On Wed, 29 Nov 2017 10:59:34 -0600
Justin Hibbits <jrh29 at alumni.cwru.edu> wrote:

> On Wed, Nov 29, 2017 at 10:13 AM, Konstantin Belousov
> <kostikbel at gmail.com> wrote:
> > 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().
> >  
> 
> I see the same breakage on PowerPC with the dtsec(4) driver, which
> pins interrupts to CPUs, now causing interrupts to migrate to cores
> without the matching portal mapping.
> 
> - Justin
> _______________________________________________
> svn-src-head at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to
> "svn-src-head-unsubscribe at freebsd.org"


I can not understand why this untested patch isn't reverted already. It
brings down any system I have at hand within short time and if someone
is stupid enough - like me - performing an installworld while new
kernel already has been installed, the old binaries, one day old, seem
to be incompatible and BTX immediately bails out.

I brought down the fourth box - by intention and the problem is serious
and can be reproduced easily.