From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752165AbbCVX5r (ORCPT ); Sun, 22 Mar 2015 19:57:47 -0400 Received: from shards.monkeyblade.net ([149.20.54.216]:49993 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751938AbbCVX5p (ORCPT ); Sun, 22 Mar 2015 19:57:45 -0400 Date: Sun, 22 Mar 2015 19:57:43 -0400 (EDT) Message-Id: <20150322.195743.1225936659717870427.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 In-Reply-To: References: <20150322.182311.109269221031797359.davem@davemloft.net> 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 16:57:45 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Linus Torvalds Date: Sun, 22 Mar 2015 16:49:51 -0700 > On Sun, Mar 22, 2015 at 3:23 PM, David Miller wrote: >> >> 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" > > Maybe. But it does seem like Bob Picco has narrowed it down to memmove(). > > It also bothers me enormously - and perhaps unreasonably - how that > memcpy code has memory barriers in it. I can see _zero_ reason for a > memory barrier inside a memcpy, unless the memcpy does something that > isn't valid to begin with. Are the VIS operatiosn perhaps using some > kind of non-temporal form that doesn't follow the TSO rules? Kind of > like the "movnt" that Intel has? The special cache line clearing stores (the ASI_BLK_INIT_QUAD_LDD_P stuff) do not adhere to the memory model. I had elided the memory barriers originally, but it caused memory corruption. So yes, this is similar to the 'movnt' situation.