svn commit: r242274 - head/sys/sys
Attilio Rao
attilio at freebsd.org
Mon Oct 29 13:13:53 UTC 2012
On 10/29/12, Gleb Smirnoff <glebius at 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
More information about the svn-src-all
mailing list