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=-14.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 07D0EC432C0 for ; Mon, 2 Dec 2019 16:23:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B11F020722 for ; Mon, 2 Dec 2019 16:23:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="sj4TdVpf" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B11F020722 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 32BA16B0003; Mon, 2 Dec 2019 11:23:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DBA56B0006; Mon, 2 Dec 2019 11:23:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CA936B0007; Mon, 2 Dec 2019 11:23:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0053.hostedemail.com [216.40.44.53]) by kanga.kvack.org (Postfix) with ESMTP id 05FF56B0003 for ; Mon, 2 Dec 2019 11:23:47 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id A70D5813F for ; Mon, 2 Dec 2019 16:23:46 +0000 (UTC) X-FDA: 76220722452.23.hot15_78326a79dbe61 X-HE-Tag: hot15_78326a79dbe61 X-Filterd-Recvd-Size: 6669 Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Mon, 2 Dec 2019 16:23:45 +0000 (UTC) Received: by mail-wm1-f68.google.com with SMTP id b11so392067wmj.4 for ; Mon, 02 Dec 2019 08:23:45 -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:content-transfer-encoding; bh=cRQJ6ECPW1QrFqWRJURD/HlVlkS5E9XfXfE0FLxYNGE=; b=sj4TdVpftHxqcOYBAMaKfRnFNNRXiSz/XA8rnq8DE6n7/x4RphySb33Mxto1kqsad3 BlNmQGLo9yQGatc9Uo6WtSfX+xysta2Czd73pGL0+0gUqEUM4SIHHSFUK1d2BQt1Pu3H 2ZSOv4IcsgJGN/bz6K2KgjLcTGUClImDZ8GEXQ1HDNqJcwL5ChHdI+apd1F5KSfM5TTQ XhZqII5U0mbzFY+DuB5LPgBGpS0mDr3vvcPds/tcVWT6kpSopH/bIk8NIKzY2UrIjSJw Tb57C+X9oPD7/m6V/WZvPYKS8cJyJu/s7U5ilR9uiFt2xSa0idtrVHwQBnk1GnjbDTM+ L/Ww== 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:content-transfer-encoding; bh=cRQJ6ECPW1QrFqWRJURD/HlVlkS5E9XfXfE0FLxYNGE=; b=NTSnp6sqSn0TA4ovdYc9YUk4ao4sfdfzUJu1vrwlJMeVgFftRYkm842VGDDmsvMYfA /5hQS+ZO8e7dkOq8RHMQZJ1Q3jje5R146mDN9dpisJVRQY3ob7HuaCzmIGcMOUOlLJBq CyzB4+l2ZpGVGVHMHyuwDg4f67H/4uaOQPFDlosyRnfIVdCPaSIctTR+Jx1wxt/de1Y8 7a/juL3I4JRCW6LiB/ftPe5m+rvsGHn5hKKjkdd3V4YCHeeL4Ou1Fpv8dow5apDRuy62 e4225hH+Cx1wqtBTJMfBpoPm9zUQmsGjeD7Nwuw2HnpUIeaLW5C7CMfZyde9fUvvfj4C RoVA== X-Gm-Message-State: APjAAAUM9giUuStCcmdP27K7SImTW5dcYXHmbY28yLPBD6+K4o268R8x iMaxJZhEOH9qQmk6Ac5zAqzjSpWYIwVkzIqLwWJYOg== X-Google-Smtp-Source: APXvYqw6oIyjni2yi9wN/lR+bxFB4HL0j9MpkrNCFgcNNlJhDMLgl7JxwihktTkAV4NZ2GhPTR4xMCSs3cJrKiQpnZE= X-Received: by 2002:a1c:2e91:: with SMTP id u139mr24424989wmu.154.1575303824093; Mon, 02 Dec 2019 08:23:44 -0800 (PST) MIME-Version: 1.0 References: <20191122112621.204798-1-glider@google.com> <20191122112621.204798-32-glider@google.com> In-Reply-To: From: Alexander Potapenko Date: Mon, 2 Dec 2019 17:23:32 +0100 Message-ID: Subject: Re: [PATCH RFC v3 31/36] kmsan: disable strscpy() optimization under KMSAN To: Marco Elver Cc: Vegard Nossum , Dmitry Vyukov , Linux Memory Management List , Al Viro , Andreas Dilger , Andrew Morton , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Christoph Hellwig , Christoph Hellwig , "Darrick J. Wong" , "David S. Miller" , Dmitry Torokhov , Eric Biggers , Eric Dumazet , Eric Van Hensbergen , Greg Kroah-Hartman , Harry Wentland , Herbert Xu , Ilya Leoshkevich , Ingo Molnar , Jason Wang , Jens Axboe , Marek Szyprowski , Mark Rutland , "Martin K. Petersen" , Martin Schwidefsky , Matthew Wilcox , "Michael S. Tsirkin" , Michal Simek , Petr Mladek , Qian Cai , Randy Dunlap , Robin Murphy , Sergey Senozhatsky , Steven Rostedt , Takashi Iwai , "Theodore Ts'o" , Thomas Gleixner , Vasily Gorbik , Wolfram Sang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Dec 2, 2019 at 4:51 PM Marco Elver wrote: > > On Fri, 22 Nov 2019 at 12:28, wrote: > > > > Disable the efficient 8-byte reading under KMSAN to avoid false positiv= es. > > > > Signed-off-by: Alexander Potapenko > > To: Alexander Potapenko > > Cc: Vegard Nossum > > Cc: Dmitry Vyukov > > Cc: linux-mm@kvack.org > > > > --- > > > > Change-Id: I25d1acf5c3df6eff85894cd94f5ddbe93308271c > > --- > > lib/string.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/lib/string.c b/lib/string.c > > index 08ec58cc673b..15efdc51bda6 100644 > > --- a/lib/string.c > > +++ b/lib/string.c > > @@ -186,7 +186,10 @@ ssize_t strscpy(char *dest, const char *src, size_= t count) > > if (count =3D=3D 0 || WARN_ON_ONCE(count > INT_MAX)) > > return -E2BIG; > > > > -#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS > > +/** > > Why a doc comment? Will fix, thanks! > > + * Disable the efficient 8-byte reading under KMSAN to avoid false pos= itives. > > + */ > > AFAIK the CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS case is about > unaligned accesses crossing page boundaries. In the #else case it's > still going to do word-at-a-time if both src and dest are aligned, so > the comment above is somewhat inaccurate. Yes, this makes little sense. Reading word-at-a-time shouldn't induce any errors, although it may generate redundant stack IDs for values that will never be used. I'll try to drop this patch. > > +#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && !defined(CONFIG= _KMSAN) > > /* > > * If src is unaligned, don't cross a page boundary, > > * since we don't know if the next page is mapped. > > -- > > 2.24.0.432.g9d3f5f5b63-goog > > --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg