From owner-freebsd-arm@FreeBSD.ORG Tue Oct 11 22:40:13 2011 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 575361065782 for ; Tue, 11 Oct 2011 22:40:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0371B8FC08 for ; Tue, 11 Oct 2011 22:40:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9BMeCF6040748 for ; Tue, 11 Oct 2011 22:40:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9BMeCQ5040747; Tue, 11 Oct 2011 22:40:12 GMT (envelope-from gnats) Date: Tue, 11 Oct 2011 22:40:12 GMT Message-Id: <201110112240.p9BMeCQ5040747@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: Mark Tinguely Cc: Subject: Re: arm/161498: [patch] ARM RAS code can fail to restart an atomic sequence. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Tinguely List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 22:40:13 -0000 The following reply was made to PR arm/161498; it has been noted by GNATS. From: Mark Tinguely To: Ian Lepore Cc: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: arm/161498: [patch] ARM RAS code can fail to restart an atomic sequence. Date: Tue, 11 Oct 2011 17:13:30 -0500 On 10/11/2011 12:42 PM, Ian Lepore wrote: > The "normal" RAS sequence goes like this: > > On entry, RAS_START = 0x00000000, RAS_END = 0xffffffff > > 1: Set RAS_START to address of Step 1 > 2: Set RAS_END to address of Step 4 > 3: Do the atomic operation > 4: Set RAS_START to 0x00000000 > 5: Set RAS_END to 0xffffffff good job! I am looking forward to ARMv6/ARMv7 to replace these with ldrex/strex/clrex calls. Devil's advocate: a person can now put any value in RAS_START and wait for an interrupt. I don't see that doing them any good. In the past they could do this only if the (RAS_START < PC). In a uni-processor, we cannot overlap these critical sections. We are assuming that critical sections are made by an atomic command because we do not check to see if (RAS_START < PC). Does the RAS_END comparison buy us anything? At this point. RAS_END == 0xffff_ffff when interrupt is between step 1 and 2 RAS_END == address of step 5 In both cases, (PC <= RAS_END) --Mark.