d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

amd64: prevent KCSan false positives on LAPIC mapping

Browse Source 
For configurations without x2APIC support (guests, older hardware), the global
LAPIC MMIO mapping will trigger false-positive KCSan reports as it will appear
that multiple CPUs are concurrently reading and writing the same address.
This isn't actually true, as the underlying physical access will be performed
on the local CPU's APIC. Additionally, because LAPIC access can happen during
event timer configuration, the resulting KCSan printf can produce a panic due
to attempted recursion on event timer resources.

Add a __nosanitizethread preprocessor define to prevent the compiler from
inserting TSan hooks, and apply it to the x86 LAPIC accessors.

PR:		249149
Reported by:	gbe
Reviewed by:	andrew, kib
Tested by:	gbe
Differential Revision:	https://reviews.freebsd.org/D26354
This commit is contained in:
Jason A. Harmening 2020-09-12 07:04:00 +00:00
parent 7d5522e16a
commit 3966af52f3
Notes: svn2git 2020-12-20 02:59:44 +00:00 
svn path=/head/; revision=365652
2 changed files with 15 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
sys/sys/cdefs.h
View File

@ -880,8 +880,10 @@
*/
#if __has_attribute(no_sanitize) && defined(__clang__)
#define __nosanitizeaddress __attribute__((no_sanitize("address")))
#define __nosanitizethread __attribute__((no_sanitize("thread")))
#else
#define __nosanitizeaddress
#define __nosanitizethread
#endif
/* Guard variables and structure members by lock. */

16
sys/x86/x86/local_apic.c
View File

@ -215,7 +215,17 @@ SYSCTL_INT(_hw_apic, OID_AUTO, timer_tsc_deadline, CTLFLAG_RD,
static void lapic_calibrate_initcount(struct lapic *la);
static void lapic_calibrate_deadline(struct lapic *la);
static uint32_t
/*
* Use __nosanitizethread to exempt the LAPIC I/O accessors from KCSan
* instrumentation. Otherwise, if x2APIC is not available, use of the global
* lapic_map will generate a KCSan false positive. While the mapping is
* shared among all CPUs, the physical access will always take place on the
* local CPU's APIC, so there isn't in fact a race here. Furthermore, the
* KCSan warning printf can cause a panic if issued during LAPIC access,
* due to attempted recursive use of event timer resources.
*/
static uint32_t __nosanitizethread
lapic_read32(enum LAPIC_REGISTERS reg)
{
uint32_t res;
@ -228,7 +238,7 @@ lapic_read32(enum LAPIC_REGISTERS reg)
return (res);
}
static void
static void __nosanitizethread
lapic_write32(enum LAPIC_REGISTERS reg, uint32_t val)
{
@ -241,7 +251,7 @@ lapic_write32(enum LAPIC_REGISTERS reg, uint32_t val)
}
}
static void
static void __nosanitizethread
lapic_write32_nofence(enum LAPIC_REGISTERS reg, uint32_t val)
{