Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp461286imm; Fri, 3 Aug 2018 06:22:05 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdOJo8UPBDEz47xa2FqhzHw8n6strnPLUKWjMidqTvdJCIy55Es/yfmP2ynaSRzlL+aOefC X-Received: by 2002:a63:a619:: with SMTP id t25-v6mr3741035pge.288.1533302525495; Fri, 03 Aug 2018 06:22:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533302525; cv=none; d=google.com; s=arc-20160816; b=WyPpwkGxS9bpMNvdRbQ6/HW/YFS4HcMQerSv9HScoA+RCg7eMW3GJN4UmAytmdXq/U tKVPv3mg48Hb117IV3WyQk5bWq1u73p1x0FBg+sFF35Ze3jG96V1tkOn8KapQi9VTGRy +eSozEFhDnInp4nEdaABuZ0ERmY5g4B4miuoNt8xK8V8dLfuH+d2Ar5Fkx1L/XkER73x F7OE261Nnh9OGg+zbOoNbjCS1DzKNjbx/E/4NvtacKB0ZNWgJuEkT2TCA7j8kcdrGcVW AhukB1tD9X5pmU8FwOEcCc5uRR3TEERS7Acl4TZqZbnjKPDlALb86xjP0wrsVzgIDLus XvTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=bDLmJ9qqB7zkqBrODNUpz0uGon2mBOSMerlQbEwvSGY=; b=N3bmTZuNe+jqS+W3xjDd7wMVrLcN/shewkC1z4iwbjNm103BC4kLa+DY6QlwRBUdRd OIcv4kqxZykyrxrIoLlJ60sbaIkzpsUcqDl99wNIlc/GbQpX4uJaPjdo29IlV41t3w+q gQvFkEYRhtTYGsTEeuY8xsotWf8CZaofpMvYA/uSjNuLodu1zEGAyi0mZGgFCkKqzxq2 cGXYGSjiS13zG8eT3Bbhbyzx94NgE3YrnnxQgdlqZ2uaHJh8WxpIXLX9MoeUfQY5+I2T VYm+yAmQJKTXUDFT0w/8eVyusmtZwc6pCt2vwDQr7pDjMVMUB45UhX2dfWcQgDIGv83B fy4Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 31-v6si4366734pld.84.2018.08.03.06.21.50; Fri, 03 Aug 2018 06:22:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732119AbeHCPRB (ORCPT + 99 others); Fri, 3 Aug 2018 11:17:01 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:53342 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728300AbeHCPRB (ORCPT ); Fri, 3 Aug 2018 11:17:01 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E91B97788E; Fri, 3 Aug 2018 13:20:41 +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 9E4F610CD6B3; Fri, 3 Aug 2018 13:20:41 +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 w73DKfMQ027965; Fri, 3 Aug 2018 09:20:41 -0400 Received: from localhost (mpatocka@localhost) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4/Submit) with ESMTP id w73DKeKL027961; Fri, 3 Aug 2018 09:20:40 -0400 X-Authentication-Warning: file01.intranet.prod.int.rdu2.redhat.com: mpatocka owned process doing -bs Date: Fri, 3 Aug 2018 09:20:40 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: Florian Weimer cc: Andrew Pinski , Catalin Marinas , Will Deacon , linux@armlinux.org.uk, thomas.petazzoni@free-electrons.com, linux-arm-kernel@lists.infradead.org, LKML , GNU C Library Subject: Re: framebuffer corruption due to overlapping stp instructions on arm64 In-Reply-To: <9acdacdb-3bd5-b71a-3003-e48132ee1371@redhat.com> Message-ID: References: <9acdacdb-3bd5-b71a-3003-e48132ee1371@redhat.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.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 03 Aug 2018 13:20:42 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 03 Aug 2018 13:20:42 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.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 Fri, 3 Aug 2018, Florian Weimer wrote: > On 08/03/2018 09:11 AM, Andrew Pinski wrote: > > Yes fix Links not to use memcpy on the framebuffer. > > It is undefined behavior to use device memory with memcpy. > > Some (de facto) ABIs require that it is supported, though. For example, > the POWER string functions avoid unaligned loads and stores for this > reason because the platform has the same issue with device memory. And > yes, GCC will expand memcpy on POWER to something that is incompatible > with device memory. 8-( > > If we don't want people to use memcpy, we probably need to provide a > credible alternative. > > Thanks, > Florian And what does POWER do with code like this? void write_merge(int *x) { x[0] = x[1] = 0; } With -O2, gcc-8 translates it into: li 9,0 std 9,0(3) blr And that std instruction may end up being unaligned (the C ABI mandates that x is aligned to 4 bytes, not 8). If this piece of code is inside some graphics driver and writes to framebuffer memory, what do you do with it? Mikulas