From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751943AbbCVWXS (ORCPT <rfc822;w@1wt.eu>);
	Sun, 22 Mar 2015 18:23:18 -0400
Received: from shards.monkeyblade.net ([149.20.54.216]:49515 "EHLO
	shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751875AbbCVWXQ (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 22 Mar 2015 18:23:16 -0400
Date: Sun, 22 Mar 2015 18:23:11 -0400 (EDT)
Message-Id: <20150322.182311.109269221031797359.davem@davemloft.net>
To: torvalds@linux-foundation.org
Cc: david.ahern@oracle.com, sparclinux@vger.kernel.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Subject: Re: 4.0.0-rc4: panic in free_block
From: David Miller <davem@davemloft.net>
In-Reply-To: <CA+55aFwEq09vwnxPEYr67O7nuOEN9_n-uJKX11qSbuBNGJVghg@mail.gmail.com>
References: <CA+55aFwXmDom=GKE=K2QVqp_RUtOPQ0v5kCArATqQEKUOZ6OrA@mail.gmail.com>
	<20150322.133603.471287558426791155.davem@davemloft.net>
	<CA+55aFwEq09vwnxPEYr67O7nuOEN9_n-uJKX11qSbuBNGJVghg@mail.gmail.com>
X-Mailer: Mew version 6.6 on Emacs 24.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Sun, 22 Mar 2015 15:23:15 -0700 (PDT)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun, 22 Mar 2015 12:47:08 -0700

> Which was why I was asking how sure you are that memcpy *always*
> copies from low to high.

Yeah I'm pretty sure.

> I don't even know which version of memcpy ends up being used on M7.
> Some of them do things like use VIS. I can follow some regular sparc
> asm, there's no way I'm even *looking* at that. Is it really ok to use
> VIS registers in random contexts?

Yes, using VIS how we do is alright, and in fact I did an audit of
this about 1 year ago.  This is another one of those "if this is
wrong, so much stuff would break"

The only thing funny some of these routines do is fetch 2 64-byte
blocks of data ahead in the inner loops, but that should be fine
right?

On the M7 we'll use the Niagara-4 memcpy.

Hmmm... I'll run this silly sparc kernel memmove through the glibc
testsuite and see if it barfs.