From owner-svn-src-all@freebsd.org Wed Nov 29 18:37:15 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E646E6548D; Wed, 29 Nov 2017 18:37:15 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F8997FF60; Wed, 29 Nov 2017 18:37:14 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from hermann ([78.52.117.12]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MePcd-1eTdjR1P03-00QBDt; Wed, 29 Nov 2017 19:36:58 +0100 Date: Wed, 29 Nov 2017 19:36:52 +0100 From: "Hartmann, O." To: Justin Hibbits Cc: Konstantin Belousov , Hans Petter Selasky , src-committers , John Baldwin , "svn-src-all@freebsd.org" , KrishnamRaju ErapaRaju , Konstantin Belousov , Nathan Whitehorn , "svn-src-head@freebsd.org" , "O. Hartmann" Subject: Re: svn commit: r326218 - head/sys/kern Message-ID: <20171129193647.77859f62@hermann> In-Reply-To: References: <201711252341.vAPNf5Qx001464@repo.freebsd.org> <14322447.103fKFTi3y@ralph.baldwin.cx> <3fc45d5f-22b9-0562-278b-c515e36f48e7@freebsd.org> <14058479.lc6xlYgyBM@ralph.baldwin.cx> <2e752d6a-d34a-dde0-acea-fdbf8bebea51@selasky.org> <20171129161356.GA2272@kib.kiev.ua> Organization: walstatt.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:J5ivfFK6aKP4S2InQoAR6D9Iymq1XYLkDu+tICdvwJYqxADaNQj h+eU6gCGdYqr+KkvLLS89Uf90GqCTC5SUsAK5OzGuMooQoG6KDsaTkR7FPwQ5EDwUX9JHGT /iv9+mLQgdS3V22mCmbyzAAGaphZjL0KHLIr8l/YX4ALnuXlAbyKvo6WtThnsGhvg01Iszb oGEYlE/AsjnGJ+WsAtf7A== X-UI-Out-Filterresults: notjunk:1;V01:K0:rqILWROsx8g=:XTT4bTKXQc/j01y+ViFxuR bYZF6x+qNZz65E+Y0ZnmOt09lD/MRzL3Iid9WVz++HEtmUM9iFVvlsj3x/b1XGD0sZKVFzgBR s6RlLDYBPz4HT7F9RFYWoHsfAafah8yuaAknoxpn0nTVQMJIRmNUnUGZmjFd4u6VWOXvPV5oN zmGDXOn+pGd/D0Be9jCj5XfSDDPub9K2okCtxmsEvNMPoX939YVoY08QXRzLe3RI7hN6Cn0Of o7z9O6rAv+Lup12LQSrHsp8TZglHbAz7eUO7GB32MkEe5cTZShw2C7vJTYhMfYsoSI6a2t19+ kMGXgYvWJ98K+gR0WZkMbB+Rv5bW6my9kWfi57djqulNweqSZSA2vfoMu9mLvwU3RcFFrwXfv IAmVZyNdlFn+d6cw5LD7yO10+ea9W0C5KhPlzYJ9vmQl3h8MWuEYGm7R7hfDz43bIJfLiGaRW +rdzjiBss8PUd4oGDHHPsB0mO7/ohBR6Fq7cN0yt+f0rsgYDYsii8tLUB52dVhyU0Q7lBg6Yb 5+t4rJOipa8nL2sAWu55QuFrFkoeMVxczCdQ5jBw3y8w6fI2k62CYIswwaIHGm+v94Lzov3s6 5wjwPg7cqJmzVkOikuNyxSiruFX3OXFmg36dUO5zcu49eiiqD9y6mZ19e1f31y+yepqhyjxka aN3xgZsyVb0Ud1Bp81j4vS6nfYHfMraLjBvD2AMpONyaqU/ajmtlzr9hNNTzavahIhnlKeCWZ hay8n0KpOQx5Myp36JB/m7lhvQ3J9YkU0/zHCz4WCsfJjrNM51MzgM6fem7j647dXkotd4Gko /kOZbstYK1KVHC7T35M1pFY/SIJg2jJDLlICC/2jEKw/oKw/ew= X-Mailman-Approved-At: Wed, 29 Nov 2017 19:00:21 +0000 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 18:37:15 -0000 On Wed, 29 Nov 2017 10:59:34 -0600 Justin Hibbits wrote: > On Wed, Nov 29, 2017 at 10:13 AM, Konstantin Belousov > 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to > "svn-src-head-unsubscribe@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.