Date: Tue, 8 Jan 2013 08:28:40 -0800 From: Oleksandr Tymoshenko <gonzo@bluezbox.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r245147 - head/sys/arm/include Message-ID: <EAD5C0F8-20BC-4A43-9DAC-0080E29EA574@bluezbox.com> In-Reply-To: <20130108155641.GG82219@kib.kiev.ua> References: <201301080240.r082eKVq080302@svn.freebsd.org> <20130108030022.GC82219@kib.kiev.ua> <50EBA947.1030902@freebsd.org> <20130108155641.GG82219@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2013-01-08, at 7:56 AM, Konstantin Belousov <kostikbel@gmail.com> wrote: > On Mon, Jan 07, 2013 at 09:06:15PM -0800, Oleksandr Tymoshenko wrote: >> 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. > I am more concerned with the following: > assume that current content in the page is 0x200:u, 0x201:v, and a byte > x was written at A+0x200, byte y at B+0x201. Is it possible that > future read of the bytes at A+0x200, A+0x201 (on the same core) > returns (x, v) ? On ARMv7 - no, it's not possible. On ARMv6 - it seems to be possible from what I gather. >> >> 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. > I am trying to find a way through the ARM ARM and some additional texts. > Could it be that cache aliasing is only limited to the I-cache on ARM, > at least for recent cores ? My concern is hopefully not valid than. > > Hm, it seems, according to the link below, that ARMv6 is affected. > >> >> Some info on subject: >> http://blogs.arm.com/software-enablement/716-page-colouring-on-armv6-and-a-bit-on-armv7/ > > This seems to support the idea that mmap does not work on ARM, at least > for ARMv6. It seems that sf buffers do not obey the arch requirements > for aliasing as well. > > Thank you for the link.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EAD5C0F8-20BC-4A43-9DAC-0080E29EA574>