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 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 171C2C282DD for ; Thu, 9 Jan 2020 22:18:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D232A21744 for ; Thu, 9 Jan 2020 22:18:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D232A21744 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 6C3118E0005; Thu, 9 Jan 2020 17:18:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 64CB38E0001; Thu, 9 Jan 2020 17:18:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 513AB8E0005; Thu, 9 Jan 2020 17:18:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0084.hostedemail.com [216.40.44.84]) by kanga.kvack.org (Postfix) with ESMTP id 365EE8E0001 for ; Thu, 9 Jan 2020 17:18:40 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id D8B21281A for ; Thu, 9 Jan 2020 22:18:39 +0000 (UTC) X-FDA: 76359511158.13.move16_2e747c6548e2e X-HE-Tag: move16_2e747c6548e2e X-Filterd-Recvd-Size: 5596 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Thu, 9 Jan 2020 22:18:39 +0000 (UTC) Received: from mail-qt1-f174.google.com ([209.85.160.174]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MkEdF-1jZRCe22uX-00kjsE for ; Thu, 09 Jan 2020 23:18:37 +0100 Received: by mail-qt1-f174.google.com with SMTP id j5so200314qtq.9 for ; Thu, 09 Jan 2020 14:18:37 -0800 (PST) X-Gm-Message-State: APjAAAUPzzEu6W7EfNZ44IdgxbcmCB37JfBcvfiRxlsisYniJUU1PChs aawUSJI8KcInO9bXP9tcuV/oHRIpv1IGFPOsa7A= X-Google-Smtp-Source: APXvYqyCldy0Ka9H3KPZOYA/NiPXlHDkyyuq1q6gfwdEk/9ehsfCQhAByOxz/z9x1AuUpDN4mQv3MJjohH3WzwWquts= X-Received: by 2002:ac8:709a:: with SMTP id y26mr9914629qto.304.1578608316155; Thu, 09 Jan 2020 14:18:36 -0800 (PST) MIME-Version: 1.0 References: <20200107214042.855757-1-arnd@arndb.de> <20200108102602.43d4c5433eb495cdbf387e9b@kernel.org> <20200109140202.fd5488a2ac02f81b25d83b88@linux-foundation.org> In-Reply-To: <20200109140202.fd5488a2ac02f81b25d83b88@linux-foundation.org> From: Arnd Bergmann Date: Thu, 9 Jan 2020 23:18:19 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] kallsyms: work around bogus -Wrestrict warning To: Andrew Morton Cc: Masami Hiramatsu , Oleksandr Natalenko , Linux-MM , Arnaldo Carvalho de Melo , Will Deacon , Song Liu , Alexey Dobriyan , Marc Zyngier , Thomas Gleixner , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:K1h+UQKDyE31soDw6X/wPe/EXQYhjulJ/u2Yj1W2ltdqq6rW/TC 0oRmvb6PcFPgeLoQ+K2Q/oHxL0lzPEAB6HQfN+4V9JHOztTH4W/6Ou1tQpMAsKpYOBkYitv HOzdsiP4toz0eT7nUuaGVLsdAH+K+UgbKu7xe7x37DNyrk+kXS05/Nb4gKyAoNIPHjHiFNb ADwWID4umncxjHeeuu5Lg== X-UI-Out-Filterresults: notjunk:1;V03:K0:t161LdpD6aw=:Cd6cJGVoPZbuy3BSxRat2R f3pEK4ePkVc8pNBAAwdqP8lWu3o5zCIwETjhBOLv8qdR2DMlRDArajD330cdIf1FI+Br7MNK0 uUXVy3M4Qd1JcUjvDbvvBna+M6ARGy1mRFtK3mrqVBfZTRSxbTd+yA+dn2WWCBbzRLf851bom OEVNh3V9++HHQl1vJFmiUrvTxI2Lhl8HGjWf1psZyunhXd7Tzz0U4JHPzGw48/phPgoJVzD0S 8gF78EHuBnKVcTqWk8JAbg+CJ6kBhmNhIhF7B5T34r8p89pfe2GLSP1lgPoCI4mSd2LHDD2Ek WkoBCKxeUHyNfld9m1+PUWHw6gXXTXfFs0zbsiTEEOTLYwtnubcpSOJd+i4N7mo/U8DTAJi+p 8fFgi8x/MhSWsr67vfzkrFKfnIMYojPIpGwnGFAp5EXskfpkJ1U3vBDt8Ao8GG4a+sIQcM2K0 nRBWuQsmQSDR7Z1l8ifbU0NHhQrid1O2RA5YfO3dN4o6oirS8hwV1yHx5nj6iPN3QqBaDo+AI yyf0cd/SvWtNB28Jn9tOuxWwqWcUItcCwuQG/gtAAGEVqD1ZW2VWhtk0bVDs34ZsVDLlUnf51 SCRCDK2lYMxRkHA3fvpgdp/9vTCSums6IMaZVgWcQKblw9ps7Ps+nHjXNMnW83RoBQRZJhB51 szcTuSQcBg7rDuBTT8YeHC8BBl5tdu71BEsJUb09R3favL1OTELEiTGb5/JG0usjLK8t3C5t/ jXrfem9wqywijJqDxjuvXVM8sbj0ys6M0RryZ9KO87emwFAuaoCI/RkOWSjdGPFCX87BVZLKH tQVxUWC2xjghCMASWbBgX9cIEdSojFNfeZDn9EEKslE+LV71DINGoU7oMDF8fhnQKe98+B4O3 4oHusiLjMJOBzLO6N5yQ== 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, Jan 9, 2020 at 11:02 PM Andrew Morton wrote: > > On Wed, 8 Jan 2020 10:26:02 +0900 Masami Hiramatsu wrote: > > > Hi Arnd, > > > > On Tue, 7 Jan 2020 22:40:26 +0100 > > Arnd Bergmann wrote: > > > > > gcc -O3 produces some really odd warnings for this file: > > > > > > kernel/kallsyms.c: In function 'sprint_symbol': > > > kernel/kallsyms.c:369:3: error: 'strcpy' source argument is the same as destination [-Werror=restrict] > > > strcpy(buffer, name); > > > ^~~~~~~~~~~~~~~~~~~~ > > > kernel/kallsyms.c: In function 'sprint_symbol_no_offset': > > > kernel/kallsyms.c:369:3: error: 'strcpy' source argument is the same as destination [-Werror=restrict] > > > strcpy(buffer, name); > > > ^~~~~~~~~~~~~~~~~~~~ > > > kernel/kallsyms.c: In function 'sprint_backtrace': > > > kernel/kallsyms.c:369:3: error: 'strcpy' source argument is the same as destination [-Werror=restrict] > > > strcpy(buffer, name); > > > ^~~~~~~~~~~~~~~~~~~~ > > > > > > This obviously cannot be since it is preceded by an 'if (name != buffer)' > > > check. > > > > Hmm, this looks like a bug in gcc. > > Yes, we're getting a lot of such reports. I don't think current gcc is > ready for this patch so I'll drop it, sorry. I've been building with gcc-8 and got around 20 false positive warnings, three real bugs and a few files that introduce increased stack usage. I have sent patches for every one of these and have a clean randconfig builds again on arm, arm64 and x86 (a few thousand so far). Most of the false-positive warnings are for understandable reasons and easy to work around, the one above is probably the most blatant screwup by gcc. My feeling is that we can deal with the warnings here and I wouldn't mind getting it enabled in mainline from that perspective, but there are two caveats: - v5.6 is probably too early since we're close to the merge window and a lot of my fixups have not been merged yet - I have no good estimate of how many runtime failures there will be. Oleksandr hasn't found any issues after running with -O3 kernels for a longer time, but any significant change to the toolchain likely causes problems for somebody. Arnd