Date: Mon, 29 Oct 2012 01:35:17 +0000 (UTC) From: Attilio Rao <attilio@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r242274 - head/sys/sys Message-ID: <201210290135.q9T1ZHUJ047280@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: attilio Date: Mon Oct 29 01:35:17 2012 New Revision: 242274 URL: http://svn.freebsd.org/changeset/base/242274 Log: Compiler have a precise knowledge of the content of sched_pin() and sched_unpin() as they are functions static and inline. This way it can do two dangerous things: - Reorder instructions around both of them, taking out from the safe path operations that are supposed to be (ie. per-cpu accesses) - Cache the value of td_pinned in CPU registers not making visible in kernel context to the scheduler once it is scanning the runqueue, as td_pinned is not marked volatile. In order to avoid both possible bugs explicitly, protect the safe path with compiler memory barriers. This will prevent reordering and caching by the compiler about td_pinned operations. Generally this could lead to suboptimal code traversing the pinnings but this is not the case as can be easilly verified: http://lists.freebsd.org/pipermail/svn-src-projects/2012-October/005797.html Discussed with: jeff, jhb MFC after: 2 weeks Modified: head/sys/sys/sched.h Modified: head/sys/sys/sched.h ============================================================================== --- head/sys/sys/sched.h Mon Oct 29 00:51:53 2012 (r242273) +++ head/sys/sys/sched.h Mon Oct 29 01:35:17 2012 (r242274) @@ -151,11 +151,13 @@ static __inline void sched_pin(void) { curthread->td_pinned++; + __compiler_membar(); } static __inline void sched_unpin(void) { + __compiler_membar(); curthread->td_pinned--; }
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201210290135.q9T1ZHUJ047280>