Date: Mon, 29 Oct 2012 09:02:21 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Attilio Rao <attilio@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r242274 - head/sys/sys Message-ID: <20121029050221.GM70741@FreeBSD.org> In-Reply-To: <201210290135.q9T1ZHUJ047280@svn.freebsd.org> References: <201210290135.q9T1ZHUJ047280@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 29, 2012 at 01:35:17AM +0000, Attilio Rao wrote: A> Author: attilio A> Date: Mon Oct 29 01:35:17 2012 A> New Revision: 242274 A> URL: http://svn.freebsd.org/changeset/base/242274 A> A> Log: A> Compiler have a precise knowledge of the content of sched_pin() and A> sched_unpin() as they are functions static and inline. This way it A> can do two dangerous things: A> - Reorder instructions around both of them, taking out from the safe A> path operations that are supposed to be (ie. per-cpu accesses) A> - Cache the value of td_pinned in CPU registers not making visible A> in kernel context to the scheduler once it is scanning the runqueue, A> as td_pinned is not marked volatile. A> A> In order to avoid both possible bugs explicitly, protect the safe path A> with compiler memory barriers. This will prevent reordering and caching A> by the compiler about td_pinned operations. A> A> Generally this could lead to suboptimal code traversing the pinnings A> but this is not the case as can be easilly verified: A> http://lists.freebsd.org/pipermail/svn-src-projects/2012-October/005797.html Now __compiler_membar() can be removed from kern_rmlock.c:360 -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121029050221.GM70741>