From owner-cvs-src@FreeBSD.ORG Fri Dec 7 22:07:20 2007 Return-Path: Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D2BC16A419; Fri, 7 Dec 2007 22:07:20 +0000 (UTC) (envelope-from cognet@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 0D37C13C45A; Fri, 7 Dec 2007 22:07:20 +0000 (UTC) (envelope-from cognet@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.1/8.14.1) with ESMTP id lB7M7Jl6032843; Fri, 7 Dec 2007 22:07:19 GMT (envelope-from cognet@repoman.freebsd.org) Received: (from cognet@localhost) by repoman.freebsd.org (8.14.1/8.14.1/Submit) id lB7M7Jv3032842; Fri, 7 Dec 2007 22:07:19 GMT (envelope-from cognet) Message-Id: <200712072207.lB7M7Jv3032842@repoman.freebsd.org> From: Olivier Houchard Date: Fri, 7 Dec 2007 22:07:19 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-FreeBSD-CVS-Branch: RELENG_7 Cc: Subject: cvs commit: src/sys/arm/include asmacros.h atomic.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2007 22:07:20 -0000 cognet 2007-12-07 22:07:19 UTC FreeBSD src repository Modified files: (Branch: RELENG_7) sys/arm/include asmacros.h atomic.h Log: MFC: sys/arm/include/asmacros.h rev 1.7 sys/arm/include/atomic.h rev 1.23 Close a race. The RAS implementation would set the end address, then the start address. These were used by the kernel to restart a RAS sequence if it was interrupted. When the thread switching code ran, it would check these values and adjust the PC and clear them if it did. However, there's a small flaw in this scheme. Thread T1, sets the end address and gets preempted. Thread T2 runs and also does a RAS operation. This resets end to zero. Thread T1 now runs again and sets start and then begins the RAS sequence, but is preempted before the RAS sequence executes its last instruction. The kernel code that would ordinarily restart the RAS sequence doesn't because the PC isn't between start and 0, so the PC isn't set to the start of the sequence. So when T1 is resumed again, it is at the wrong location for RAS to produce the correct results. This causes the wrong results for the atomic sequence. The window for the first race is 3 instructions. The window for the second race is 5-10 instructions depending on the atomic operation. This makes this failure fairly rare and hard to reproduce. Mutexs are implemented in libthr using atomic operations. When the above race would occur, a lock could get stuck locked, causing many downstream problems, as you might expect. Also, make sure to reset the start and end address when doing a syscall, or a malicious process could set them before doing a syscall. Reviewed by: imp, ups (thanks guys) Approved by: re (kensmith) Pointy hat to: cognet Revision Changes Path 1.6.2.1 +8 -1 src/sys/arm/include/asmacros.h 1.21.2.1 +44 -20 src/sys/arm/include/atomic.h