kern/187238: vm.pmap.pcid_enabled="1" causes Java to coredump in FBSD 10

[Henrik Gulbrandsen]

It looks like any attempt to send an email to this list without being
subscribed means that you end up in moderation indefinitely, so I try
to send again, just in case there are other people out there that have
been working on this bug. I have been running my test (java/openjdk6
rebuilding itself) continuously for 59 hours now. That used to fail
most of the time, but I haven't seen a single crash with this patch.

/Henrik

-------- Original Message --------
Subject: Re: kern/187238: vm.pmap.pcid_enabled="1" causes Java to 
coredump in FBSD 10
Date: 2014-03-18 11:54
 From: Henrik Gulbrandsen <henrik at gulbra.net>
To: bug-followup at FreeBSD.org, freebsd-java at FreeBSD.org
Cc: Craig Rodrigues <rodrigc at FreeBSD.org>, Konstantin Belousov 
<kib at FreeBSD.org>, Alan Cox <alc at FreeBSD.org>

This is the most time-consuming bug I've encountered in my life, and not
only because I started looking for it in the JVM, but now it seems to 
have
been hiding in plain sight. I'm pretty sure that pmap->pm_save is 
handled
incorrectly in the current kernel. Judging from the code, it's supposed 
to
include all CPUs where the pmap has been active since the latest call to
pmap_invalidate_all(...). However, that means that it should always be a
superset of pmap->pm_active, since any CPU where the pmap is active may
cache pmap information at any time. Currently, this is not the case, and
since only CPUs in pmap->pm_save are targeted in the TLB shootdown, we
are left with inconsistencies that crash the process soon afterwards.

The attached patch solves this by only clearing a CPU from pmap->pm_save
if it is not currently included in pmap->pm_active. As far as I can 
tell,
that eliminates the bug. The patch is against STABLE, since that's what
I'm currently running, but CURRENT should be pretty close, except for 
the
default setting of pmap_pcid_enabled.

By the way, the logic in the invalidation functions is a bit messy now
and can probably be simplified. Also, is there a good reason for 
ignoring
the pmap argument in smp_masked_invltlb(...)?

/Henrik