From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753370AbbCWTwi (ORCPT ); Mon, 23 Mar 2015 15:52:38 -0400 Received: from shards.monkeyblade.net ([149.20.54.216]:57764 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752460AbbCWTwf (ORCPT ); Mon, 23 Mar 2015 15:52:35 -0400 Date: Mon, 23 Mar 2015 15:52:32 -0400 (EDT) Message-Id: <20150323.155232.650842650739774037.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, bpicco@meloft.net Subject: Re: 4.0.0-rc4: panic in free_block From: David Miller In-Reply-To: References: <20150323.150833.1435862810481480096.davem@davemloft.net> X-Mailer: Mew version 6.5 on Emacs 24.1 / 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]); Mon, 23 Mar 2015 12:52:35 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Linus Torvalds Date: Mon, 23 Mar 2015 12:47:49 -0700 > On Mon, Mar 23, 2015 at 12:08 PM, David Miller wrote: >> >> Sure you could do that in C, but I really want to avoid using memcpy() >> if dst and src overlap in any way at all. >> >> Said another way, I don't want to codify that "64" thing. The next >> chip could do 128 byte initializing stores. > > But David, THAT IS NOT WHAT YOUR BROKEN ASM DOES ANYWAY! > > Read it again. Your asm code does not check for overlap. Look at this: > > cmp %o0, %o1 > bleu,pt %xcc, 2f > > and ponder. It's wrong. Right, it's not checking for overlap. It's checking for "does a forward copy work?" That's the standard test for this, and it's what glibc uses in it's generic memmove() implementation FWIW. (granted, I know glibc is not generally a good source for "right way to do things :-) > The new asm version is better than the old one, because the new > breakage is about really bad performance rather than actively > breaking, but still.. I accept that it's suboptimal.