Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp157388imu; Tue, 15 Jan 2019 18:49:15 -0800 (PST) X-Google-Smtp-Source: ALg8bN4vbs8ShK28D+mdPKyLD6wz6epxjWQ8WGI5BGfRpDwVgasVpkgNS98HDLDAqg6gr+huqa8u X-Received: by 2002:a62:5c41:: with SMTP id q62mr7433463pfb.171.1547606955051; Tue, 15 Jan 2019 18:49:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547606955; cv=none; d=google.com; s=arc-20160816; b=I40It7yfP6+BW/6tDU/V6ZU0EbM2BgPR+Ckvl8otlZRHteU7X5LfVkRf+SqbxvLuP4 FjUt/gNPM0jgM+RNcxMtfOyQU/kfSY/mhNNsscWT7MgSdK0nkCCXsz34yqK6/ZxJfnWP Q/1qrujxEHT0xljUtyeo7R9aGdAgP6v0cRMDtfLW5r53FYZ8ZvXXrvQNe3+BQCRT3ybC 78ZbGWgzHJ+Xl+c0QhfGcDbzC9HCGMtqS07Sc3A5hqxDFbI0m1zJD+EOzIXW5BeIye8y KCQ23hMthjLSLDzOWlsMpxamSkOiwa8iYjTKMGto0WQhiz0HnYBOGerxoSMvOQZmELKp 9flw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=vtRv+bC2b+ZKIpllhcnEkC8mS52A6059IN3SfIUvhCc=; b=lmoxf6W6MQ3R4lHgNxfl748Echc5k3NAITsiVaPmsx6YINFKZx0zRcRhYKNXdOLmRR k3muQanMG1Zdan97fada2h5zKZwYHJEhXeuB4Alvj2I4SyKhYJ+Sh/GwZxMX+XkhTYnf W4idTcDekU+FxSATGSCkuDs+2mWmkv7BTncexf5OMJXHBIu/RkEieJv80pwKgbFzkjJs vx/rttj4sehUpom4fp9jA97gpb4TrnLUuJuc2CSIgp70raIE5GKOuCUGVdtv+3dJoO1k hqIjw4bj09QMWPfvxcxkqdBWlhmEXxLm972a95PbrtLDHbQrrUT3ahaABukizYH3WvEj 9gjw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=IGysP+d3; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b12si4779028pls.32.2019.01.15.18.48.58; Tue, 15 Jan 2019 18:49:15 -0800 (PST) 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; dkim=pass header.i=@google.com header.s=20161025 header.b=IGysP+d3; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732170AbfAORLE (ORCPT + 99 others); Tue, 15 Jan 2019 12:11:04 -0500 Received: from mail-it1-f195.google.com ([209.85.166.195]:37924 "EHLO mail-it1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728566AbfAORLD (ORCPT ); Tue, 15 Jan 2019 12:11:03 -0500 Received: by mail-it1-f195.google.com with SMTP id h65so5389354ith.3 for ; Tue, 15 Jan 2019 09:11:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vtRv+bC2b+ZKIpllhcnEkC8mS52A6059IN3SfIUvhCc=; b=IGysP+d3tnbyPkdQg4vGdHxuFQrail167z6JMr/frchJzjv7q3yRaRlzOcRW9l86JL wsWZXal0fnZQGv8Glipj9178hYrmvcdVihCkzxW0MQayUNNX/c+amOxro+cWUKhnTtCc dWd4a3sTN9rD63+34rBUiOTNhtzvEyhRF3sPnK1ks494cI6mQQk/x+KAHwAfBJuPAt/0 /tnNQMA2fyVQkBqT8o7k4oupI4yjCD+9wf8/kyA42dXhJ4Ipw3d+wHivQgeWgdXGgJQc 9BUxZ1P6xYI7OCCnX5Nu9EfCg0dnpL1oEKAECoN7dagit0YeU4KCiqCOhRWvnDb1Gtzs QT9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vtRv+bC2b+ZKIpllhcnEkC8mS52A6059IN3SfIUvhCc=; b=g/l3cQmelMDY1YpjZo241YciqmEviHwkFW3qgdaZZi6wEyf4QagBpDngaoqybasEP1 IpEdals3z1WwfMDeng45Wd3IuteZdohBj4xIggsKxxa4AkDdH34g1d+7lRmXBeXWm3gO No0tYwIgNwcmt2yXjbqL5f8MPLGrV8sV9yENQyGIK/iGPWzGMYIX1hmxD6CbQufKhyWc U2zVLdliJ0plzvMamckl4PSXN3w5AoVEoRoNyWm9Au4o3/H6dO5z+xsO/34qVZbBysx2 o59Di1yhaT0YNGIL9kOFlu9rDDkoNzLMbOlRBjTxVCMpzvWvVjMlAqCcL7cdsIAfJgyC 2H+w== X-Gm-Message-State: AJcUuke4dzY9jM3d6y2Nhpgek21PsVhX1mvZwNduA4evXKsNFvGkJxtu 8ppxLlmyn8vbgip57j5JeaiwoQSy8NXZUvfcPBR9BgJn X-Received: by 2002:a05:660c:f94:: with SMTP id x20mr2787821itl.144.1547572262348; Tue, 15 Jan 2019 09:11:02 -0800 (PST) MIME-Version: 1.0 References: <0c854dd6b110ac2b81ef1681f6e097f59f84af8b.1547289808.git.christophe.leroy@c-s.fr> <801c7d58-417d-1e65-68a0-b8cf02f9f956@c-s.fr> <330696c0-90c6-27de-5eb3-4da2159fdfbc@virtuozzo.com> In-Reply-To: <330696c0-90c6-27de-5eb3-4da2159fdfbc@virtuozzo.com> From: Dmitry Vyukov Date: Tue, 15 Jan 2019 18:10:51 +0100 Message-ID: Subject: Re: [PATCH v3 1/3] powerpc/mm: prepare kernel for KAsan on PPC32 To: Andrey Ryabinin Cc: Christophe Leroy , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Nicholas Piggin , "Aneesh Kumar K.V" , Alexander Potapenko , LKML , linuxppc-dev@lists.ozlabs.org, kasan-dev , Linux-MM Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 15, 2019 at 6:06 PM Andrey Ryabinin wrote: > > > > On 1/15/19 2:14 PM, Dmitry Vyukov wrote: > > On Tue, Jan 15, 2019 at 8:27 AM Christophe Leroy > > wrote: > >> On 01/14/2019 09:34 AM, Dmitry Vyukov wrote: > >>> On Sat, Jan 12, 2019 at 12:16 PM Christophe Leroy > >>> wrote: > >>> > > >>> > In kernel/cputable.c, explicitly use memcpy() in order > >>> > to allow GCC to replace it with __memcpy() when KASAN is > >>> > selected. > >>> > > >>> > Since commit 400c47d81ca38 ("powerpc32: memset: only use dcbz once cache is > >>> > enabled"), memset() can be used before activation of the cache, > >>> > so no need to use memset_io() for zeroing the BSS. > >>> > > >>> > Signed-off-by: Christophe Leroy > >>> > --- > >>> > arch/powerpc/kernel/cputable.c | 4 ++-- > >>> > arch/powerpc/kernel/setup_32.c | 6 ++---- > >>> > 2 files changed, 4 insertions(+), 6 deletions(-) > >>> > > >>> > diff --git a/arch/powerpc/kernel/cputable.c > >>> b/arch/powerpc/kernel/cputable.c > >>> > index 1eab54bc6ee9..84814c8d1bcb 100644 > >>> > --- a/arch/powerpc/kernel/cputable.c > >>> > +++ b/arch/powerpc/kernel/cputable.c > >>> > @@ -2147,7 +2147,7 @@ void __init set_cur_cpu_spec(struct cpu_spec *s) > >>> > struct cpu_spec *t = &the_cpu_spec; > >>> > > >>> > t = PTRRELOC(t); > >>> > - *t = *s; > >>> > + memcpy(t, s, sizeof(*t)); > >>> > >>> Hi Christophe, > >>> > >>> I understand why you are doing this, but this looks a bit fragile and > >>> non-scalable. This may not work with the next version of compiler, > >>> just different than yours version of compiler, clang, etc. > >> > >> My felling would be that this change makes it more solid. > >> > >> My understanding is that when you do *t = *s, the compiler can use > >> whatever way it wants to do the copy. > >> When you do memcpy(), you ensure it will do it that way and not another > >> way, don't you ? > > > > It makes this single line more deterministic wrt code-gen (though, > > strictly saying compiler can turn memcpy back into inlines > > instructions, it knows memcpy semantics anyway). > > But the problem I meant is that the set of places that are subject to > > this problem is not deterministic. So if we go with this solution, > > after this change it's in the status "works on your machine" and we > > either need to commit to not using struct copies and zeroing > > throughout kernel code or potentially have a long tail of other > > similar cases, and since they can be triggered by another compiler > > version, we may need to backport these changes to previous releases > > too. Whereas if we would go with compiler flags, it would prevent the > > problem in all current and future places and with other past/future > > versions of compilers. > > > > The patch will work for any compiler. The point of this patch is to make > memcpy() visible to the preprocessor which will replace it with __memcpy(). For this single line, yes. But it does not mean that KASAN will work. > After preprocessor's work, compiler will see just __memcpy() call here.