Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3370316imu; Mon, 14 Jan 2019 01:36:30 -0800 (PST) X-Google-Smtp-Source: ALg8bN6OFzmGIo9DwxhvH8Ic59BU45A9rLfXcS+49LQeoZbq/HyEwJKdVcGPlGCC/NVGxhZalj6b X-Received: by 2002:a17:902:4523:: with SMTP id m32mr24473574pld.53.1547458590606; Mon, 14 Jan 2019 01:36:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547458590; cv=none; d=google.com; s=arc-20160816; b=nuI+qtusfgAFsM+PdnRjN5jjJ5YyMiQ9nXq53obm9q3GC2+xZMxVF1yPUCnrPk7Ngi nQoFym6r9oR+ELQB/KcL+e75DrqCWpm3HRvHvykdYtpmjyMWwOoV9zzz4qs6UaDShO/o ppJ0ltEnlSBBqhYgUan/IEbDY6JIi71RSeIdJFS+2myvYWYjNOXXQtn88MZnmBcHdfih DMr06KQarSasowULLd0I8iUqfECVag72ArCXIvEbwg8q4W8Y4SnZFS3olhOpmAEoglGs lOc0vQbAxI3s61UiwtV267cjjriy8OcCL/j3ew9Y0ef8cRPE5aH35vd71wv6D6Jh0uy/ hPQg== 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=Pn0/rZ2B5GkSLOkvstRq19Y+ZB+KVKjQ5D4UTrTEcFQ=; b=zYgFm+5Hb4hfzEYOp67ldghfjtVNOTNzJo5NM+PeVSKdheXAut6lIcaMBGhU+J7cQr GnS1dMSVjqRvDPtPtnrjzua/B/n+2SYbNACX9CGes+xEIotnPnmOB3Cehvr50LSHGNns DH44UTnsi3N8no2alkj4WEcyJXYs1hcPfsgpuEnFp/gJAkDVZkWdzsVoIYVH6uBDznJy VOEx6TnfS3kzabU67Yc2Y74vdA8gpe0nPFyNRioYdh5DOKYy4zYYy/T3xJzm+KH6Djwu yqLtCjiH2yxSYVxIOGXQCOcbcsOTY/MXl4CgTj+ymsaoBuPDlftLFeQuZJpF0mYFwN5x u2bQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=cG3zM3rO; 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 i90si20782410pli.135.2019.01.14.01.36.15; Mon, 14 Jan 2019 01:36:30 -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=cG3zM3rO; 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 S1726579AbfANJfG (ORCPT + 99 others); Mon, 14 Jan 2019 04:35:06 -0500 Received: from mail-io1-f67.google.com ([209.85.166.67]:43234 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726064AbfANJfF (ORCPT ); Mon, 14 Jan 2019 04:35:05 -0500 Received: by mail-io1-f67.google.com with SMTP id b23so17068196ios.10 for ; Mon, 14 Jan 2019 01:35:04 -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=Pn0/rZ2B5GkSLOkvstRq19Y+ZB+KVKjQ5D4UTrTEcFQ=; b=cG3zM3rOJqP9xq8n8LMwEKTXJUQ4xh2O+zaaNyos6gkTdiT0UhD5YRj4zebrVQCK79 lTszCU7lJZs+wRyNh/NZEjWDrwgO2XiRVx6xv0Ra/FQU9iclaLSOhmErIuO/HUVBzWr2 nP3swD1jtKwthtzn03IXwPV9QFMWMIlVuHp1iQ0d6KMQztjWe8TBkSZdAUMrRjMh6WUN nStPiAZ/dUsrozxjVmfHco6C7wBa+7K1swBrAUHWvFubg/nw/9+fY4NJgHI7e9+NBb5/ WSU1YAmgtOKm2strY0meX98AhNuQy8M3JmpV81bLo/b6PGT3C4i+VArU5y5WdeeW+yk+ q0SQ== 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=Pn0/rZ2B5GkSLOkvstRq19Y+ZB+KVKjQ5D4UTrTEcFQ=; b=Y3EwStg87R9NLL9B0EU3oNwpUUbYBIoiUijH3RkRFYeug9MiQjlsCPq2sJKcDe3eKv rbfbkIMpo1dNM0VMdXt4xNlc6oBJUPZbz+kQWa7nEPYnkxS3BtMTPWhC16LhJpkeOVZN 22p4RGHj/sshDuKY/AiGjLDZYQJ4jbsrO4XTdndGS2Of2dH38Taj3DQcEos0uUzv8OV6 bIlOto5zXLm3KuM5oTzoc1A/gIWqyBDII+7JUYzDY6+3pNpPQm3J+YQOJ9Ex9XeuEa61 ZzJpisAHRHtRsAP3Iyhhq6028jyLWiUNQlc5ACuejraFb26gbqQ9STU4Q/Si1LaZTO5V XgDg== X-Gm-Message-State: AJcUukfFupyeFef6Pi/0T5dBH/IzgZzN8FEGHM6skgv4U8LIWiYHWr3J 1ygqwqgMKFgkB/oe4WiYtGY98Nv6KiwUrYjIRhVXjg== X-Received: by 2002:a6b:fa01:: with SMTP id p1mr9451772ioh.271.1547458504276; Mon, 14 Jan 2019 01:35:04 -0800 (PST) MIME-Version: 1.0 References: <0c854dd6b110ac2b81ef1681f6e097f59f84af8b.1547289808.git.christophe.leroy@c-s.fr> In-Reply-To: <0c854dd6b110ac2b81ef1681f6e097f59f84af8b.1547289808.git.christophe.leroy@c-s.fr> From: Dmitry Vyukov Date: Mon, 14 Jan 2019 10:34:52 +0100 Message-ID: Subject: Re: [PATCH v3 1/3] powerpc/mm: prepare kernel for KAsan on PPC32 To: Christophe Leroy Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Nicholas Piggin , "Aneesh Kumar K.V" , Andrey Ryabinin , 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 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. Does using -ffreestanding and/or -fno-builtin-memcpy (-memset) help? If it helps, perhaps it makes sense to add these flags to KASAN_SANITIZE := n files. > *PTRRELOC(&cur_cpu_spec) = &the_cpu_spec; > } > @@ -2162,7 +2162,7 @@ static struct cpu_spec * __init setup_cpu_spec(unsigned long offset, > old = *t; > > /* Copy everything, then do fixups */ > - *t = *s; > + memcpy(t, s, sizeof(*t)); > > /* > * If we are overriding a previous value derived from the real > diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c > index 947f904688b0..5e761eb16a6d 100644 > --- a/arch/powerpc/kernel/setup_32.c > +++ b/arch/powerpc/kernel/setup_32.c > @@ -73,10 +73,8 @@ notrace unsigned long __init early_init(unsigned long dt_ptr) > { > unsigned long offset = reloc_offset(); > > - /* First zero the BSS -- use memset_io, some platforms don't have > - * caches on yet */ > - memset_io((void __iomem *)PTRRELOC(&__bss_start), 0, > - __bss_stop - __bss_start); > + /* First zero the BSS */ > + memset(PTRRELOC(&__bss_start), 0, __bss_stop - __bss_start); > > /* > * Identify the CPU type and fix up code sections > -- > 2.13.3 >