From owner-svn-src-all@FreeBSD.ORG Tue Jan 8 05:06:27 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 899B1DC; Tue, 8 Jan 2013 05:06:27 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 25EAAA66; Tue, 8 Jan 2013 05:06:26 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TsROC-0004oB-Ry; Mon, 07 Jan 2013 21:06:18 -0800 Message-ID: <50EBA947.1030902@freebsd.org> Date: Mon, 07 Jan 2013 21:06:15 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: svn commit: r245147 - head/sys/arm/include References: <201301080240.r082eKVq080302@svn.freebsd.org> <20130108030022.GC82219@kib.kiev.ua> In-Reply-To: <20130108030022.GC82219@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 1/7/2013 7:00 PM, Konstantin Belousov wrote: > On Tue, Jan 08, 2013 at 02:40:20AM +0000, Oleksandr Tymoshenko wrote: >> Author: gonzo >> Date: Tue Jan 8 02:40:20 2013 >> New Revision: 245147 >> URL: http://svnweb.freebsd.org/changeset/base/245147 >> >> Log: >> Switch default cache type for ARMv6/ARMv7 from write-through to >> writeback-writeallocate > Could you, please, describe how this is supposed to work. > > Assume that a process mapped the same file page at two different > addresses, both read-write, and writes to both mappings. Usermode code > does not consider the need to flush caches or synchronize writes into > non-overlapping regions, usually. Would it break, i.e. could the values > appear in the page which were never written to it ? [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 05:06:27 -0000 On 1/7/2013 7:00 PM, Konstantin Belousov wrote: > On Tue, Jan 08, 2013 at 02:40:20AM +0000, Oleksandr Tymoshenko wrote: >> Author: gonzo >> Date: Tue Jan 8 02:40:20 2013 >> New Revision: 245147 >> URL: http://svnweb.freebsd.org/changeset/base/245147 >> >> Log: >> Switch default cache type for ARMv6/ARMv7 from write-through to >> writeback-writeallocate > Could you, please, describe how this is supposed to work. > > Assume that a process mapped the same file page at two different > addresses, both read-write, and writes to both mappings. Usermode code > does not consider the need to flush caches or synchronize writes into > non-overlapping regions, usually. Would it break, i.e. could the values > appear in the page which were never written to it ? I might misunderstood question so let me rephrase it: One physical page P, virtual addresses A and B both mapped to it. Two conditions should be true: - if I write word to A+0x200 same value should appear at B+0x200 next time it is read - If there are no writes to P either through A or B each next read should yield same result. These conditions are met for ARMv7 devices for both WT and WBWA caches. They're PIPT so no aliasing in this case. Up until now I believed that "no aliasing" is true for all ARM CPUs we target but quick check proved me wrong: ARM1176 on which Raspberry Pi is based is prone to cache aliasing problem. Which might explain memory corruption easily reproducible under load. Again the problem is not related to cache type itself but to the lack of handling of this situation in pmap module. Some info on subject: http://blogs.arm.com/software-enablement/716-page-colouring-on-armv6-and-a-bit-on-armv7/ Thank you for raising this topic. I hope people more ARM-savvy then me can confirm or refute my point of view. > > Another similar question, sf buffers on ARM flush the cache on sf_buf_free() > (sometimes). If the page, for which the sf buffer is created, mapped into > the userspace read-write, could it be that a value appears that was never > written ? Note that sf buffers are used e.g. by uiomove_fromphys(). I believe the stuff above is applicable to this question too.