Date: Thu, 9 Mar 2017 16:25:17 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Alexandre Martins <alexandre.martins@stormshield.eu> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: smp_rendezvous_action: Are atomics correctly used ? Message-ID: <20170309142516.GA16105@kib.kiev.ua> In-Reply-To: <3034263.GEZH9i4V44@pc-alex> References: <2092905.6A8RAGlt18@pc-alex> <4355496.HzrDjoMEL6@pc-alex> <20170309130754.GX30979@kib.kiev.ua> <3034263.GEZH9i4V44@pc-alex>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 09, 2017 at 02:52:09PM +0100, Alexandre Martins wrote: > Le jeudi 9 mars 2017, 15:07:54 Konstantin Belousov a ?crit : > > On Thu, Mar 09, 2017 at 10:59:27AM +0100, Alexandre Martins wrote: > > > I have the save question for the cpu_ipi_pending here: > > > > > > https://svnweb.freebsd.org/base/head/sys/x86/x86/mp_x86.c?view=annotate#l1 > > > 080> > > > Le jeudi 9 mars 2017, 10:43:14 Alexandre Martins a ?crit : > > > > Hello, > > > > > > > > I'm curently reading the code of the function smp_rendezvous_action, in > > > > kern/subr_smp.c file. In that function, i see that the variable > > > > smp_rv_waiters is read in some while() loop in a non-atomic way. > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annotate#l > > > > 412 > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annotate#l > > > > 458 > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annotate#l > > > > 472 > > > > > > > > I suspect one of my freeze to be due by that. > > > > You should provide either evidence or, at least, some reasoning supporting > > your claims. > > I curently have a software watchdog that triger and does a coredump. In the > coredumps, I always see a CPU trying to write-lock a "rm lock". Every time, > that CPU is spinning into the smp_rendezvous_action, in the first while loop) > while the others are into the idle threads. > > The fact is that freeze is not clear and I start to search "exotic" causes to > explain it. This sounds as the 'usual' deadlock, where some other thread owns rmlock in read mode. I recommend you to follow the https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170309142516.GA16105>