Date: Sat, 14 Feb 2015 18:57:08 +0000 From: "ian (Ian Lepore)" <phabric-noreply@FreeBSD.org> To: freebsd-arm@freebsd.org Subject: [Differential] [Commented On] D1810: Leave HYP mode upon startup Message-ID: <a0e0edad46575a6b55180ee2c4d9bc91@localhost.localdomain> In-Reply-To: <differential-rev-PHID-DREV-3jnmioetq2qo5zfr5ol4-req@FreeBSD.org> References: <differential-rev-PHID-DREV-3jnmioetq2qo5zfr5ol4-req@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a0e0edad46575a6b55180ee2c4d9bc91>