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=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 742BBC433E0 for ; Fri, 5 Jun 2020 10:35:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3208B2075B for ; Fri, 5 Jun 2020 10:35:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=axtens.net header.i=@axtens.net header.b="bz7SUp/X" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3208B2075B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=axtens.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A72A08E0007; Fri, 5 Jun 2020 06:35:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A23358E0006; Fri, 5 Jun 2020 06:35:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9385E8E0007; Fri, 5 Jun 2020 06:35:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0120.hostedemail.com [216.40.44.120]) by kanga.kvack.org (Postfix) with ESMTP id 7AEB48E0006 for ; Fri, 5 Jun 2020 06:35:26 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3E1D5824556B for ; Fri, 5 Jun 2020 10:35:26 +0000 (UTC) X-FDA: 76894801452.25.laugh80_160c40c26d9f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin25.hostedemail.com (Postfix) with ESMTP id 154F31804E3A1 for ; Fri, 5 Jun 2020 10:35:26 +0000 (UTC) X-HE-Tag: laugh80_160c40c26d9f X-Filterd-Recvd-Size: 4830 Received: from mail-pj1-f68.google.com (mail-pj1-f68.google.com [209.85.216.68]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Fri, 5 Jun 2020 10:35:25 +0000 (UTC) Received: by mail-pj1-f68.google.com with SMTP id jz3so2431383pjb.0 for ; Fri, 05 Jun 2020 03:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=VlguKipBlwqSV59iaN5HNwHnW3vx2wDAI39ZqC5acwI=; b=bz7SUp/XUMCCGXe+XUWE7d8cGROObFnhBc2H8iF96Cs/lLhkBecSD3rMGehHr5WKHV eJO3euSHay9BkxTc7FXAdfyYRjh+1UvEzRV+9BX40PsP6A83Iq5dqkN4cy33DLxwjN43 4j1EXv2aSzSKSljd2WmHTPpiNJUju4DapkVIQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=VlguKipBlwqSV59iaN5HNwHnW3vx2wDAI39ZqC5acwI=; b=fF7xJ2DpBhtutgJZmf9+jBx8ROkOG2vH1JErZvPWoj3LANbDK3blihavydJxAhMSdE M3L347+UVnQewy6qb+tMw+Sbpu5nv3xK20K+giGkzCkMZt/qkjt0fImKnvlUCjAM04Dw fAUAyaRAiq0LzwgbOj4qYspwd9UlBfVjjZP5joUdSOv+kB73W5pW+J8GbRcNXqXdu/SZ iBLDz7WGwIA9y9miLqVnFzqZcamO7mfnH05D0dVxpXnViBibDo6aavxQQo6N4Pufpx3i //wC0OZMgx77BUHqOpxHEpBw38xCGUMH0HTpEMX/d1E/soFZsHeJvGrjavPJkd1Lqjyn bYuA== X-Gm-Message-State: AOAM533pGversu/AtpQPKRlBHw/1ORm+faoXXdV+lxYGjVzck8VWLsDW PFoQhT67T5B2dkctiMhBMYOm/A== X-Google-Smtp-Source: ABdhPJx5jgmiqaicKDp93lPvf3eGge89rwpznUfvZuy8HkHVD1eQZhURpTzidt4r6AM5XgW65pwqBQ== X-Received: by 2002:a17:90a:dd42:: with SMTP id u2mr2279590pjv.65.1591353324747; Fri, 05 Jun 2020 03:35:24 -0700 (PDT) Received: from localhost (2001-44b8-1113-6700-f1e1-8c06-62c8-bd7b.static.ipv6.internode.on.net. [2001:44b8:1113:6700:f1e1:8c06:62c8:bd7b]) by smtp.gmail.com with ESMTPSA id j186sm7035135pfb.220.2020.06.05.03.35.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jun 2020 03:35:24 -0700 (PDT) From: Daniel Axtens To: Andrew Morton Cc: kbuild test robot , kbuild-all@lists.01.org, Johannes Weiner , Dmitry Vyukov , Linux Memory Management List Subject: Re: [hnaz-linux-mm:master 169/698] include/linux/string.h:307:9: note: in expansion of macro '__underlying_strncpy' In-Reply-To: <20200602121620.257a40752a9ce475d8a2c6c8@linux-foundation.org> References: <202005301819.G4uARaFJ%lkp@intel.com> <20200601180455.1a2f38368da33c7a0bb8d6fb@linux-foundation.org> <87wo4qywp4.fsf@dja-thinkpad.axtens.net> <87tuzuyvgt.fsf@dja-thinkpad.axtens.net> <87r1uyyptc.fsf@dja-thinkpad.axtens.net> <20200602121620.257a40752a9ce475d8a2c6c8@linux-foundation.org> Date: Fri, 05 Jun 2020 20:35:21 +1000 Message-ID: <87img5u7fa.fsf@dja-thinkpad.axtens.net> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 154F31804E3A1 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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: Andrew Morton writes: > On Tue, 02 Jun 2020 15:55:27 +1000 Daniel Axtens wrote: > >> Huh, turns out that we do actually see a similar set of warnings before >> and after this patch, they're just different warnings as a consequence >> of my patch. > > Ah. > >> Given that these warnings only show up at W=1, is there any point in >> further supressing them? > > I guess not. > > So what should we do? Go over the various sites and use memcpy(), each > with a suitably apologetic code comment explaining the reason? It's a good question. - We could disable the warning outright or demote it to W=2+. It doesn't tell us about behaviour that is definitely wrong, just suspicious, and we have a number of callsites in the kenel using it in a correct and compliant way. Wstringop-overflow catches full-on overflows (once Linus reenables it). - We could keep the warning and patch the callsites. One can make the argument that changing to memcpy makes the semantics more clear: str* in C refers to null-terminated strings, and if the string isn't null-terminated then the str* functions aren't a natural fit for manipulating it. And it means we get to keep the warning enabled to catch accidental off-by-ones. - We could do nothing. If you compile with W=1 there is a known set of warnings and you're probably more interested in the delta than in the set. I think I have a slight preference for patching the callsites and eventually promoting the warning from W=1 to always on. But I have to be honest that I'm not going to have time to do it soon, and potentially not for a few months. Regards, Daniel From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============7757903997708169339==" MIME-Version: 1.0 From: Daniel Axtens To: kbuild-all@lists.01.org Subject: Re: [hnaz-linux-mm:master 169/698] include/linux/string.h:307:9: note: in expansion of macro '__underlying_strncpy' Date: Fri, 05 Jun 2020 20:35:21 +1000 Message-ID: <87img5u7fa.fsf@dja-thinkpad.axtens.net> In-Reply-To: <20200602121620.257a40752a9ce475d8a2c6c8@linux-foundation.org> List-Id: --===============7757903997708169339== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Andrew Morton writes: > On Tue, 02 Jun 2020 15:55:27 +1000 Daniel Axtens wrote: > >> Huh, turns out that we do actually see a similar set of warnings before >> and after this patch, they're just different warnings as a consequence >> of my patch. > > Ah. > = >> Given that these warnings only show up at W=3D1, is there any point in >> further supressing them? > > I guess not. > > So what should we do? Go over the various sites and use memcpy(), each > with a suitably apologetic code comment explaining the reason? It's a good question. - We could disable the warning outright or demote it to W=3D2+. It doesn't tell us about behaviour that is definitely wrong, just suspicious, and we have a number of callsites in the kenel using it in a correct and compliant way. Wstringop-overflow catches full-on overflows (once Linus reenables it). - We could keep the warning and patch the callsites. One can make the argument that changing to memcpy makes the semantics more clear: str* in C refers to null-terminated strings, and if the string isn't null-terminated then the str* functions aren't a natural fit for manipulating it. And it means we get to keep the warning enabled to catch accidental off-by-ones. - We could do nothing. If you compile with W=3D1 there is a known set of warnings and you're probably more interested in the delta than in the set. I think I have a slight preference for patching the callsites and eventually promoting the warning from W=3D1 to always on. But I have to be honest that I'm not going to have time to do it soon, and potentially not for a few months. Regards, Daniel --===============7757903997708169339==--