On 10/29/12, Gleb Smirnoff <gleb...@freebsd.org> wrote: > 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
No, they are there to protect td_critnest which has nothing to do with sched_pin(). Attilio -- Peace can only be achieved by understanding - A. Einstein _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"