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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=unavailable 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 E7197C43219 for ; Fri, 3 May 2019 18:16:48 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 276242075C for ; Fri, 3 May 2019 18:16:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 276242075C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 44wgM13rsNzDqrN for ; Sat, 4 May 2019 04:16:45 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=permerror (mailfrom) smtp.mailfrom=kernel.crashing.org (client-ip=63.228.1.57; helo=gate.crashing.org; envelope-from=segher@kernel.crashing.org; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 44wgKR65NtzDqY4 for ; Sat, 4 May 2019 04:15:23 +1000 (AEST) Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x43IF9Dv008894; Fri, 3 May 2019 13:15:09 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x43IF8rU008889; Fri, 3 May 2019 13:15:08 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 3 May 2019 13:15:08 -0500 From: Segher Boessenkool To: Christophe Leroy Subject: Re: [PATCH] powerpc/32: Remove memory clobber asm constraint on dcbX() functions Message-ID: <20190503181508.GQ8599@gate.crashing.org> References: <20180109065759.4E54B6C73D@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Scott Wood , linuxppc-dev@lists.ozlabs.org, Paul Mackerras , linux-kernel@vger.kernel.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hi Christophe, On Fri, May 03, 2019 at 04:14:13PM +0200, Christophe Leroy wrote: > A while ago I proposed the following patch, and didn't get any comment > back on it. I didn't see it. Maybe because of holiday :-) > Do you have any opinion on it ? Is it good and worth it ? > Le 09/01/2018 à 07:57, Christophe Leroy a écrit : > >Instead of just telling GCC that dcbz(), dcbi(), dcbf() and dcbst() > >clobber memory, tell it what it clobbers: > >* dcbz(), dcbi() and dcbf() clobbers one cacheline as output > >* dcbf() and dcbst() clobbers one cacheline as input You cannot "clobber input". Seen another way, only dcbi clobbers anything; dcbz zeroes it instead, and dcbf and dcbst only change in what caches the data hangs out. > >--- a/arch/powerpc/include/asm/cache.h > >+++ b/arch/powerpc/include/asm/cache.h > >@@ -82,22 +82,31 @@ extern void _set_L3CR(unsigned long); > > > > static inline void dcbz(void *addr) > > { > >- __asm__ __volatile__ ("dcbz 0, %0" : : "r"(addr) : "memory"); > >+ __asm__ __volatile__ ("dcbz 0, %1" : > >+ "=m"(*(char (*)[L1_CACHE_BYTES])addr) : > >+ "r"(addr) :); > > } The instruction does *not* work on the memory pointed to by addr. It works on the cache line containing the address addr. If you want to have addr always aligned, you need to document this, and check all callers, etc. > > static inline void dcbf(void *addr) > > { > >- __asm__ __volatile__ ("dcbf 0, %0" : : "r"(addr) : "memory"); > >+ __asm__ __volatile__ ("dcbf 0, %1" : > >+ "=m"(*(char (*)[L1_CACHE_BYTES])addr) : > >+ "r"(addr), "m"(*(char > >(*)[L1_CACHE_BYTES])addr) : > >+ ); > > } Newline damage... Was that your mailer? Also, you may want a "memory" clobber anyway, to get ordering correct for the synchronisation instructions. I think your changes make things less robust than they were before. [ Btw. Instead of __asm__ __volatile__ ("dcbf 0, %0" : : "r"(addr) : "memory"); you can do __asm__ __volatile__ ("dcbf %0" : : "Z"(addr) : "memory"); to save some insns here and there. ] Segher