From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752872AbbCWRMe (ORCPT ); Mon, 23 Mar 2015 13:12:34 -0400 Received: from mail-ie0-f178.google.com ([209.85.223.178]:34419 "EHLO mail-ie0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752218AbbCWRMb (ORCPT ); Mon, 23 Mar 2015 13:12:31 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150323.125537.767987027704780801.davem@davemloft.net> Date: Mon, 23 Mar 2015 10:12:30 -0700 X-Google-Sender-Auth: iMaJbFOkb3wT8LCyz_aZhXN8Mo4 Message-ID: Subject: Re: [GIT] Sparc From: Linus Torvalds To: David Miller Cc: Andrew Morton , sparclinux@vger.kernel.org, Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 23, 2015 at 10:05 AM, Linus Torvalds wrote: > On Mon, Mar 23, 2015 at 9:55 AM, David Miller wrote: >> >> Some perf bug fixes from David Ahern, and the fix for that nasty >> memmove() bug. > > That doesn't seem to be marked for stable? Or do you do the same thing > as for networking, and just collect stable patches manually? Side note: the memmove commit message is a bit misleading. The old code handled zero-length calls fine, even if it wasn't explicit: it always called memmove() for that case. The condition "dst <= src || src + len <= dst" ends up being always true when len is zero (because it obviously ends up being "dst <= src || src <= dst"). So there was just one bug - the 64-byte overlap with the cacheline establish for the destination. Even that cacheline establish would have been ok if all the loads for the 64-byte block had been done up-front. Oh well. I'm actually somewhat surprised this didn't hit anything else. Doesn't networking also end up doing overlapping memmove() on the skb data occasionally? Linus From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Date: Mon, 23 Mar 2015 17:12:30 +0000 Subject: Re: [GIT] Sparc Message-Id: List-Id: References: <20150323.125537.767987027704780801.davem@davemloft.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: David Miller Cc: Andrew Morton , sparclinux@vger.kernel.org, Linux Kernel Mailing List On Mon, Mar 23, 2015 at 10:05 AM, Linus Torvalds wrote: > On Mon, Mar 23, 2015 at 9:55 AM, David Miller wrote: >> >> Some perf bug fixes from David Ahern, and the fix for that nasty >> memmove() bug. > > That doesn't seem to be marked for stable? Or do you do the same thing > as for networking, and just collect stable patches manually? Side note: the memmove commit message is a bit misleading. The old code handled zero-length calls fine, even if it wasn't explicit: it always called memmove() for that case. The condition "dst <= src || src + len <= dst" ends up being always true when len is zero (because it obviously ends up being "dst <= src || src <= dst"). So there was just one bug - the 64-byte overlap with the cacheline establish for the destination. Even that cacheline establish would have been ok if all the loads for the 64-byte block had been done up-front. Oh well. I'm actually somewhat surprised this didn't hit anything else. Doesn't networking also end up doing overlapping memmove() on the skb data occasionally? Linus