smp_rendezvous_action: Are atomics correctly used ?
Alexandre Martins
alexandre.martins at stormshield.eu
Thu Mar 9 13:50:38 UTC 2017
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.
>
> > > Should this function be patched to use
> > > "atomic_load_acq_int(&smp_rv_waiters[])" ?
>
> There too.
>
> As a side note, any read or write of the naturally aligned integer
> types with size less or equal than the machine word, on all supported
> architectures, are atomic. The meaning of the word atomic there is
> that when reading, you always get a complete value that was written by
> a writer into this location, not some out of thin air value. Similarly,
> when writing, you are guaranteed that any observer of the write will see
> the value you have wrote.
>
> The guarantees above hold both for C-level code and for the assembler
> accesses.
>
> atomic_load_acq() provides additional guarantees which do not affect the
> value read from the variable itself, but establish the ordering on the
> visibility of the related operations.
OK, I got it. Thank you !
--
Alexandre Martins
STORMSHIELD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2874 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20170309/50d5a5e3/attachment.bin>
More information about the freebsd-current
mailing list