From owner-freebsd-arm@FreeBSD.ORG Sat Feb 14 18:57:09 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 396EC65E for ; Sat, 14 Feb 2015 18:57:09 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 00E3F84C for ; Sat, 14 Feb 2015 18:57:08 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t1EIv850032179 for ; Sat, 14 Feb 2015 18:57:08 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t1EIv8dO032178; Sat, 14 Feb 2015 18:57:08 GMT (envelope-from root) Date: Sat, 14 Feb 2015 18:57:08 +0000 To: freebsd-arm@freebsd.org From: "ian (Ian Lepore)" Subject: [Differential] [Commented On] D1810: Leave HYP mode upon startup Message-ID: X-Priority: 3 Thread-Topic: D1810: Leave HYP mode upon startup X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZjlkNDcyMzZlMWIyNDBkZTI1NTY5ZjZiZGRjIFTfmoQ= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 18:57:09 -0000 ian added a comment. Replies from Wojciech Macek (who doesn't have direct write access here) 1. The write barrier. Yep, it might be not necessary. I was testing it on the revision which did not have br_prod_tail atomic. I've just removed it and run the test again, but it will take about 24h, cause the reproduction rate is really low. 2. Read barrier I wouldn't say that it prevents reordering here. It rather guarantees observability of the valid data. Im my scenario I'm running drdb_dequeue_sc/buf_ring_dequeue_sc few times in the loop. It's inline, so the compiler puts them inside the loop's body. I suspect, that the issue is possible only on cortex-a15, due to its long pipeline and advanced branch predictors. In normal case, where the ring is empty, the dequeue_sc returns NULL. But the core wants to optimize memmory accessess, so there is a chance that it preloads its readbuffers with a data that can be used in further code execution. The cons_head does not change within the function, so there is no reason why the core shouldn't early-load the br->br_ring[cons_head] pointer, which might be outdated. The core just has no knowledge that the data is valid only when prod_tail changes. Nevertheless, without rmb the buffer did not work properly - dequeue function returned some "old" mbuf which left there from the previous pas s. This is basically how I found this bug. REVISION DETAIL https://reviews.freebsd.org/D1810 To: zbb, andrew, ian Cc: imp, freebsd-arm