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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 8D80AC5DF60 for ; Thu, 7 Nov 2019 10:00:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 59D46206C3 for ; Thu, 7 Nov 2019 10:00:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 59D46206C3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CE11D6B000D; Thu, 7 Nov 2019 05:00:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C8FB26B000E; Thu, 7 Nov 2019 05:00:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B57E36B0010; Thu, 7 Nov 2019 05:00:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0224.hostedemail.com [216.40.44.224]) by kanga.kvack.org (Postfix) with ESMTP id 9D3946B000D for ; Thu, 7 Nov 2019 05:00:40 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id D50D7F031 for ; Thu, 7 Nov 2019 10:00:39 +0000 (UTC) X-FDA: 76129036998.18.burn25_7a1f60854a659 X-HE-Tag: burn25_7a1f60854a659 X-Filterd-Recvd-Size: 5978 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Thu, 7 Nov 2019 10:00:39 +0000 (UTC) Received: from mail-qk1-f176.google.com ([209.85.222.176]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MtO4E-1heOWR1jXa-00uqP3 for ; Thu, 07 Nov 2019 11:00:37 +0100 Received: by mail-qk1-f176.google.com with SMTP id m16so1401898qki.11 for ; Thu, 07 Nov 2019 02:00:36 -0800 (PST) X-Gm-Message-State: APjAAAXN/ImS64g9AEg70QM6/YIPnheHYoq5776IQfG9XMJ6+7ftdBjH etz9r/ZtVKHRHLwz4lr5R88E6MMMjb0rC/S9EWk= X-Google-Smtp-Source: APXvYqxhF8lKv0pFEpZHBVDdA4ymfJ9Wsv6VTWUv4m3EUu8ndDPWa6OeWgLySCiMMgRZxr3DUQNVeUR6LNCR2WV4RSc= X-Received: by 2002:a05:620a:a0e:: with SMTP id i14mr1841083qka.3.1573120835982; Thu, 07 Nov 2019 02:00:35 -0800 (PST) MIME-Version: 1.0 References: <20191030142237.249532-1-glider@google.com> <20191030142237.249532-3-glider@google.com> <20191101055033.GA226263@google.com> <20191107060816.GA93084@google.com> <47fdac13-fa2c-2acd-2480-5e6d4db208f8@virtuozzo.com> In-Reply-To: <47fdac13-fa2c-2acd-2480-5e6d4db208f8@virtuozzo.com> From: Arnd Bergmann Date: Thu, 7 Nov 2019 11:00:19 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC v2 02/25] stackdepot: prevent Clang from optimizing away stackdepot_memcmp() To: Andrey Ryabinin Cc: Alexander Potapenko , Sergey Senozhatsky , Vegard Nossum , Dmitry Vyukov , Linux Memory Management List , Al Viro , Andrew Morton , Andy Lutomirski , Ard Biesheuvel , Christoph Hellwig , Dmitry Torokhov , Eric Dumazet , Eric Van Hensbergen , Greg Kroah-Hartman , Harry Wentland , Herbert Xu , Ingo Molnar , Jens Axboe , "Martin K . Petersen" , Martin Schwidefsky , "Michael S. Tsirkin" , Michal Simek , Petr Mladek , Sergey Senozhatsky , Steven Rostedt , Takashi Iwai , "Theodore Ts'o" , Thomas Gleixner , Wolfram Sang , Vasily Gorbik , Ilya Leoshkevich , Mark Rutland , Matthew Wilcox , Randy Dunlap , Andrey Konovalov , Marco Elver , Nick Desaulniers , clang-built-linux Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:Und6hZM6j77ura5ze79vaXFeLn9Xm2uPi5FWWVhXGSf7dK3/Iyi orM6rqc/ThNk/44hfw+5gdMGE+HYrINX5dxF5hw5lw5v9HBzlghvjSVZNVEuhPkupTRc1M3 bjf2r9eH0a9fqmujolEHucNPtntCvOVh+LdAwSUAp3Kjgo2hSxPAadDWhw2X/BlWvbzAc88 Rb9PdUKUeS0eerZGyCGGQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:PESPquCXsug=:LwEgs/9HBNT+DLzBY9+Dak s8yBb0abH9ubCwl1CzS2Eb4/I+0BqLBqwQ0BR2OtjiREyshCMKaPrtDdHFkdq4tsuvrmWa7o/ T9pU15l3whn1/aHmPVvBuvFUiK+taAfK/TKCBU7Zs6X3JlUfEz8BkeOdmPU3v2fSjSf+1+Rec 768aVbe2iQMhBRnDr1qRxOeY34X04CYuzF+cv4PqRGOMp1qQWFecj8OE9i7aDeHU5JvzXQavo wrOQXfkIl/vCW7f1PEDsNHYaM+Dm5bXdaQV6cIw6aRzJa9uq8gtcadIsuoIJab+7xz8WPF//b orew3n8MdLPQrEOGtfB1U0gdpMBfuq8wOD+NbWLLGjISmF80ML0k5A9T6ofc8eOKO0lhKv3NN iXjBxmk5RttPH6kEZHTuo/C60q03TIbSzx7nmEh4yI1JspI93C91DdjPNlhZPL0e5YpU/3ZDf 39C/pMNC2Q/gxdLDvkLsDMg7LjQKwzaqfpPyyABacYylwBvtiQkZFnMjrVr7Ww1cNEK/GbQmF PPrAVp6ARCBTQ3exERm/5Njn13WDQRDjL7zpXIwlfEDRFjY9pTJ1OmuwpeN9/Hn7Ly9Y0k8ph +mWmETDdOSORlUgNMjRLwQA3KrmfwR8o/GH3JrKdcUsHxBHwyIjPK+1o3640nJEAyIyipIDMU R+EgXsg9fgFbArbUccYhfzLWEMLyVC+FDix8AA5XKvFBlwPCUhODI4ai+aoXUxIzPe94Il6lv ZX1/J5qjPY3HE58whgjGinJGGsWrWYPPFIdSIgIaW/hWww/RsJnEMZUQM6dUwHvs0MdmxMqJM L7wTiAqJP0UjkSA40lATbFjXpG1ZOvZsCZcGuTojcc08o+eyIcQxjnCIoGaSTbhq3uxto9pWs Y+cH91jJ8SDYnpBbu4lo3pGIYW0oe8aHqIXL0GsGkgMYy7xgScvyI1uyZz5MCJtOp/xN0c+U1 mbv4RIzIKbonoku3JlR/WSv2Af3ZpbNgDOeY6mj1ghfdxEMX+xigsIXfwSTZ7ZIa3+4NVzMAH IBjikrecwT3EL9EK0IqHTpkCXP9iHcGQgxGBM1MWnds7JwHpjD4QU2nwDBXNicfRtA== 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 Thu, Nov 7, 2019 at 10:46 AM Andrey Ryabinin wrote: > On 11/7/19 12:22 PM, Alexander Potapenko wrote: > > On Thu, Nov 7, 2019 at 10:04 AM Arnd Bergmann wrote: > >> On Thu, Nov 7, 2019 at 7:08 AM Sergey Senozhatsky > >> wrote: > >> The normal way to do a volatile access would be > >> READ_ONCE()/WRITE_ONCE(), but that seems stronger than > >> the barrier() here. I'd just stick to adding a barrier. > > I actually like the READ_ONCE idea more, as READ_ONCE is really a > > documented way to prevent the compiler from merging reads, which is > > what we want here. > > I would rather go with -fno-builtin-bcmp or maybe even -fno-builtin if that works. The commit message for 5f074f3e192f ("lib/string.c: implement a basic bcmp") mentions that -fno-builtin-bcmp did not work for LTO when the global bcmp() help was added. I don't know whether the same applies here, but my guess is that it's the same issue. Arnd