From owner-svn-src-all@freebsd.org  Mon Jan 25 17:01:01 2016
Return-Path: <owner-svn-src-all@freebsd.org>
Delivered-To: svn-src-all@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98B00A4651C;
 Mon, 25 Jan 2016 17:01:01 +0000 (UTC)
 (envelope-from andrew@fubar.geek.nz)
Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249])
 by mx1.freebsd.org (Postfix) with ESMTP id 69EE8FD6;
 Mon, 25 Jan 2016 17:01:01 +0000 (UTC)
 (envelope-from andrew@fubar.geek.nz)
Received: from zapp.Home (97e175b7.skybroadband.com [151.225.117.183])
 by kif.fubar.geek.nz (Postfix) with ESMTPSA id ACEA7D78FE;
 Mon, 25 Jan 2016 17:00:54 +0000 (UTC)
Date: Mon, 25 Jan 2016 17:00:53 +0000
From: Andrew Turner <andrew@fubar.geek.nz>
To: Konstantin Belousov <kostikbel@gmail.com>
Cc: Svatopluk Kraus <skra@FreeBSD.org>, src-committers@freebsd.org,
 svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject: Re: svn commit: r294727 - head/sys/arm/arm
Message-ID: <20160125170053.7ae20536@zapp.Home>
In-Reply-To: <20160125154453.GA3942@kib.kiev.ua>
References: <201601251409.u0PE9abE013306@repo.freebsd.org>
 <20160125154453.GA3942@kib.kiev.ua>
X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-BeenThere: svn-src-all@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: "SVN commit messages for the entire src tree \(except for &quot;
 user&quot; and &quot; projects&quot; \)" <svn-src-all.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-all>,
 <mailto:svn-src-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-all/>
List-Post: <mailto:svn-src-all@freebsd.org>
List-Help: <mailto:svn-src-all-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-all>,
 <mailto:svn-src-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jan 2016 17:01:01 -0000

On Mon, 25 Jan 2016 17:44:53 +0200
Konstantin Belousov <kostikbel@gmail.com> wrote:

> On Mon, Jan 25, 2016 at 02:09:36PM +0000, Svatopluk Kraus wrote:
> > Author: skra
> > Date: Mon Jan 25 14:09:35 2016
> > New Revision: 294727
> > URL: https://svnweb.freebsd.org/changeset/base/294727
> > 
> > Log:
> >   Fix an occasional undefined instruction abort during module
> > loading. 
> >   Even if data cache maintenance was done by IO code, the relocation
> >   fixup process creates dirty cache entries that we must write back
> >   before doing icache sync.  
> Does arm64 need the same fix ?
> 

I don't think so. On arm64 we call cpu_icache_sync_range to sync the I
and D cache. This will clean the D-Cache to the Point of Coherency,
then invalidate the I-Cache. I think this is slightly wrong as we only
need to clean to the Point of Unification.

Looking at the ARMv7 implementation of cpu_icache_sync_all is wrong, it
only invalidates the I-Cache. cpu_icache_sync_range is almost correct,
it will clean the D-Cache, with the same issue as arm64, but it is
missing a barrier after this operation, and is missing a branch
predictor invalidation.

This change seems to be working around the brokenness of the existing
cache sync operations rather than fixing them, however I don't know the
details on why this approach to fixing the issue was taken.

Andrew