From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753355AbbCWTIj (ORCPT ); Mon, 23 Mar 2015 15:08:39 -0400 Received: from shards.monkeyblade.net ([149.20.54.216]:57288 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752120AbbCWTIh (ORCPT ); Mon, 23 Mar 2015 15:08:37 -0400 Date: Mon, 23 Mar 2015 15:08:33 -0400 (EDT) Message-Id: <20150323.150833.1435862810481480096.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: <20150322.221906.1670737065885267482.davem@davemloft.net> <20150323.122530.812870422534676208.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:08:36 -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 10:00:02 -0700 > Maybe the code could be something like > > void *memmove(void *dst, const void *src, size_t n); > { > // non-overlapping cases > if (src + n <= dst) > return memcpy(dst, src, n); > if (dst + n <= src) > return memcpy(dst, src, n); > > // overlapping, but we know we > // (a) copy upwards > // (b) initialize the result in at most chunks of 64 > if (dst+64 <= src) > return memcpy(dst, src, n); > > .. do the backwards thing .. > } > > (ok, maybe I got it wrong, but you get the idea). > > I *think* gcc should do ok on the above kind of code, and not generate > wildly different code from your handcoded version. 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.