From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60B82C46470 for ; Wed, 8 Aug 2018 18:37:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1E0D121798 for ; Wed, 8 Aug 2018 18:37:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1E0D121798 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729778AbeHHU6B (ORCPT ); Wed, 8 Aug 2018 16:58:01 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:44764 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727295AbeHHU6B (ORCPT ); Wed, 8 Aug 2018 16:58:01 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E5E327B2B2; Wed, 8 Aug 2018 18:37:03 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (file01.intranet.prod.int.rdu2.redhat.com [10.11.5.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 892132156897; Wed, 8 Aug 2018 18:37:03 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (localhost [127.0.0.1]) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4) with ESMTP id w78Ib3Lt027667; Wed, 8 Aug 2018 14:37:03 -0400 Received: from localhost (mpatocka@localhost) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4/Submit) with ESMTP id w78Ib256027650; Wed, 8 Aug 2018 14:37:02 -0400 X-Authentication-Warning: file01.intranet.prod.int.rdu2.redhat.com: mpatocka owned process doing -bs Date: Wed, 8 Aug 2018 14:37:02 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: David Laight cc: "'Catalin Marinas'" , Matt Sealey , Thomas Petazzoni , Joao Pinto , Ard Biesheuvel , linux-pci , Jingoo Han , Will Deacon , Russell King , Linux Kernel Mailing List , linux-arm-kernel Subject: RE: framebuffer corruption due to overlapping stp instructions on arm64 In-Reply-To: <19c70d2a0b224db78f72dd316ad006b8@AcuMS.aculab.com> Message-ID: References: <20180803094129.GB17798@arm.com> <20180808121641.GB24736@iMac.local> <19c70d2a0b224db78f72dd316ad006b8@AcuMS.aculab.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 08 Aug 2018 18:37:04 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 08 Aug 2018 18:37:04 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'mpatocka@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 8 Aug 2018, David Laight wrote: > From: Mikulas Patocka > > Sent: 08 August 2018 14:47 > ... > > The problem on ARM is that I see data corruption when the overlapping > > unaligned writes are done just by a single core. > > Is this a sequence of unaligned writes (that shouldn't modify the > same physical locations) or an aligned write followed by an > unaligned one that updates part of the earlier write. > (Or the opposite order?) > > It might be that the unaligned writes are bypassing the write-combining > buffer (without flushing it) - so overtake the aligned write. > > Alternatively the unaligned writes go through the write-combining > buffer but the byte-enables aren't handled in the expected way. > > It ought to be possible to work out which sequence is actually broken. > > David All the unaligned/or aligned writes inside memcpy write the same value to the overlapping bytes. So, the corruption can't be explained just by reordering the writes or failing to detect hazard between them. Mikulas From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: Date: Wed, 8 Aug 2018 14:37:02 -0400 (EDT) From: Mikulas Patocka To: David Laight Subject: RE: framebuffer corruption due to overlapping stp instructions on arm64 In-Reply-To: <19c70d2a0b224db78f72dd316ad006b8@AcuMS.aculab.com> Message-ID: References: <20180803094129.GB17798@arm.com> <20180808121641.GB24736@iMac.local> <19c70d2a0b224db78f72dd316ad006b8@AcuMS.aculab.com> MIME-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Thomas Petazzoni , Joao Pinto , Ard Biesheuvel , 'Catalin Marinas' , Will Deacon , Russell King , Linux Kernel Mailing List , Matt Sealey , linux-pci , Jingoo Han , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+bjorn=helgaas.com@lists.infradead.org List-ID: On Wed, 8 Aug 2018, David Laight wrote: > From: Mikulas Patocka > > Sent: 08 August 2018 14:47 > ... > > The problem on ARM is that I see data corruption when the overlapping > > unaligned writes are done just by a single core. > > Is this a sequence of unaligned writes (that shouldn't modify the > same physical locations) or an aligned write followed by an > unaligned one that updates part of the earlier write. > (Or the opposite order?) > > It might be that the unaligned writes are bypassing the write-combining > buffer (without flushing it) - so overtake the aligned write. > > Alternatively the unaligned writes go through the write-combining > buffer but the byte-enables aren't handled in the expected way. > > It ought to be possible to work out which sequence is actually broken. > > David All the unaligned/or aligned writes inside memcpy write the same value to the overlapping bytes. So, the corruption can't be explained just by reordering the writes or failing to detect hazard between them. Mikulas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: mpatocka@redhat.com (Mikulas Patocka) Date: Wed, 8 Aug 2018 14:37:02 -0400 (EDT) Subject: framebuffer corruption due to overlapping stp instructions on arm64 In-Reply-To: <19c70d2a0b224db78f72dd316ad006b8@AcuMS.aculab.com> References: <20180803094129.GB17798@arm.com> <20180808121641.GB24736@iMac.local> <19c70d2a0b224db78f72dd316ad006b8@AcuMS.aculab.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, 8 Aug 2018, David Laight wrote: > From: Mikulas Patocka > > Sent: 08 August 2018 14:47 > ... > > The problem on ARM is that I see data corruption when the overlapping > > unaligned writes are done just by a single core. > > Is this a sequence of unaligned writes (that shouldn't modify the > same physical locations) or an aligned write followed by an > unaligned one that updates part of the earlier write. > (Or the opposite order?) > > It might be that the unaligned writes are bypassing the write-combining > buffer (without flushing it) - so overtake the aligned write. > > Alternatively the unaligned writes go through the write-combining > buffer but the byte-enables aren't handled in the expected way. > > It ought to be possible to work out which sequence is actually broken. > > David All the unaligned/or aligned writes inside memcpy write the same value to the overlapping bytes. So, the corruption can't be explained just by reordering the writes or failing to detect hazard between them. Mikulas