Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp3469432pxp; Tue, 8 Mar 2022 15:16:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJwbZ6jIWqROS/a9KVZ0G9zw1Ab8hP5NGzOm5pt81yLg5e3iKudLTJbBAgXQ1zU7W4xWJEx2 X-Received: by 2002:a05:6a00:150a:b0:4cc:f6a6:1bc6 with SMTP id q10-20020a056a00150a00b004ccf6a61bc6mr20809533pfu.74.1646781387281; Tue, 08 Mar 2022 15:16:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646781387; cv=none; d=google.com; s=arc-20160816; b=zw0As5V4K09nOxwXReSkM3Nlrv9UdpfR3czy4lfuZpab7VaoLUwX/cadyLPxR6qooo 7k+cGPQ5W5Ukfvxpvc6AJXLnLEZR02/nQG46o4I8+NPfUQxH3N6Pun6ytOubBLPMRPSN gFZd0i4Up+Fx9c1ygJHRyxq+c7ghHw27wrS8YEdVB1qxCyAAnH0IA0aClpfsnl87AsZT jafTuO4AJ3tdAJrMDJY6T47xK9orCuJqD7f8oQX/JeVsKHE8kZChn+IXyOJ9bjgZX7R8 8lBQvXyKZiqOxDPocy4FhlWBVgCEivJgC0jpceimCQQ/yvye6+IvSSJRiFiwzu27ernG XMDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=wK/gEFQ0EMRgzG6YGFBVXZAcwTR4LW/WoH16scqQvPk=; b=h8BgFJHnmWMD36FmeINbzPkN8fWXdJaujErp3JZ094TDVCRorxjyb/I3TCKD55nFme oDX05b9wKxgIFD2Du2aVOL70GWHwnzVXdnDNgDw5aJDmKV4MtddEXzOOI3keD7qRHw+j U7+Ia0NVL6Muj8FS2cdCMT6inw9xoRTO0C+QD59gtYvaIhn5ttbji67zic+02lcm85ps Aby8ZqXjyOWrFD7if5yuxN+I/wYqAHLp5Gk65wmUX5OSv/bQEsmksTSPt4Bj6JFQze9R hhZi4Ua7v72kNMfbj+7kaduBjqIJls+NEMuwcyb7YRTb7z9Cl8IxqHb/eUgyxIeUrh0/ LP3g== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id p5-20020a170902e74500b0014fbc90f619si268054plf.348.2022.03.08.15.16.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Mar 2022 15:16:27 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 869087C154; Tue, 8 Mar 2022 15:11:24 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236850AbiCGMQ4 (ORCPT + 99 others); Mon, 7 Mar 2022 07:16:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37586 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233271AbiCGMQy (ORCPT ); Mon, 7 Mar 2022 07:16:54 -0500 Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.74]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7290F7F6C9 for ; Mon, 7 Mar 2022 04:15:58 -0800 (PST) Received: from mail-wr1-f49.google.com ([209.85.221.49]) by mrelayeu.kundenserver.de (mreue109 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MEFnP-1nGyzo1WRZ-00AD3o for ; Mon, 07 Mar 2022 13:15:57 +0100 Received: by mail-wr1-f49.google.com with SMTP id j17so23015229wrc.0 for ; Mon, 07 Mar 2022 04:15:57 -0800 (PST) X-Gm-Message-State: AOAM533d7G2hr0e29uMTux1Z91h14yGRxU9qE9e7IsLtXos6T7OEvcsw RkHU6k6XWSVi6MQwwSa3tNQQ5sE5O1lE4Ed4xps= X-Received: by 2002:adf:d081:0:b0:1ef:9378:b7cc with SMTP id y1-20020adfd081000000b001ef9378b7ccmr8504005wrh.407.1646655356966; Mon, 07 Mar 2022 04:15:56 -0800 (PST) MIME-Version: 1.0 References: <20220304124416.1181029-1-mailhol.vincent@wanadoo.fr> <20220307105810.1747024-1-alexandr.lobakin@intel.com> In-Reply-To: <20220307105810.1747024-1-alexandr.lobakin@intel.com> From: Arnd Bergmann Date: Mon, 7 Mar 2022 13:15:41 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] linux/bits.h: fix -Wtype-limits warnings in GENMASK_INPUT_CHECK() To: Alexander Lobakin Cc: Andy Shevchenko , Vincent Mailhol , Rikard Falkeborn , Andrew Morton , Linux Kernel Mailing List , Arnd Bergmann , Kees Cook Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:s6FhnVSjMfCR5LY1hgq/PM1SP9EEH/EC8vHPsFUzg3jfVOQS9UY ZZa7cOm4F+d0UBUdnSE/0iD7j23rORaGmkrZzpvEld4lwD2oMN+8ihIpxXVNBjqwB0ls51s 9aFJkI87hJjpA+qejnabOIwZVJaN+JN7q2/OfZ9mMpRETjKafRSYh+7vHfPknZ5LOsAwaff b+eScCEdgwFJJGOwyVSAg== X-UI-Out-Filterresults: notjunk:1;V03:K0:p7XKEH2FvJY=:DePrBHXQ8zafj7WAME18xR 8sHcHAwaLaaPIOky1AppLHo2ZitX2cAQSVFaftaYz+tM+NgcKJ+0iLaV/v5cD3NGeR5Un8iRH 1r0VYghsSWsZIaTtSYf7mwWpafPLuW7Cz6UXcXv0pqPySbhuE6BrB+DjOAFogUJibcJR1jIp6 9c71LWsw2gDOjC45xCxgqz8fTsWdBbEP8DwntZoR5kuI7DYqfZmXsrUl7ABdMRY+y1EMtKdeq tOJxceWZpNomYaXeweyc8RBsGQmErSFzJQziz65Embw55LyShyP+PCBGetC9PBPxcWrBfL0LY Lp48hni4X4hoqPiEGZTFNvwWcdNo9rRnmwo/iS/bgHMA+h3ds0bKiYTt7ihV/vnclIll6xwjW ekz3KyDs3V8cMqevd0urabK4s/0rYgJ+U8OT+fbrej8g9vTHL6TypIDBx039Am+Pp9BWMeBxm Mso4FAd3gpVupKvnnWQvYh1O5CjGDaB/DHSDlcIaJTHHoTzwglQI85BiKBLjWtg9b106sBWHs /yyRBkgCCibvM9eh8sCGR2YDmSw/Cdi9RiMSBWoNKJxuHv4WMXQUkM3tustuSFius8SAk885B juhws2nIF+122SYopS7C+9Sa3/HV+IHtGMWHzSKEV0jBQ6pArAOJZrGv+yBMn2k9W6sX8Ybhw /DUl1edfxM1ajTyM4sBZWdEDWjHQdvFcj0xjIMqheg/IN9rLb3aoWnkkHVMFZeEqeMVP7R07p b6ewOTtRBdak5FVBOWvb6lmZXy4Zwqp82BVy1Ce2JxC48ZeXxhlAgOAcoQyIIKjuNOHI9+7ib IvQUNTFieFwWz4WozJctK6t2Dz58pWqgt1+en3VtVBXLrGyMl0= X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 7, 2022 at 11:58 AM Alexander Lobakin wrote: > From: Andy Shevchenko > > Have you fixed W=1 warnings? > > Without fixing W=1 (which makes much more sense, when used with > > WERROR=y && COMPILE_TEST=y) this has no value. > > How is this connected? > When I do `make W=2 path/to/my/code`, I want to see the actual code > problems, not something that comes from the include files. > When I do `make W=2 path/to/new/code/from/lkml`, I want to see the > actual new warnings, not something coming from the includes. > It's much easier to overlook or miss some real warnings when the > stderr is being flooded by the warnings from the include files. > I'm aware there are some scripts to compare before/after, but I > don't want to use them just because "this has to value". > I don't want to do `make W=2 KCFLAGS='-Wno-shadow -Wno-type-limits'` > because then I'm not able to spot the actual shadow or type limit > problems in my/new code. > I fixed several `-Wshadow` warnings previously in the include files > related to networking, and *nobody* said "this has no value" or > NAKed it. And `-Wshadow` has always been in W=2. I agree: if we decide that W=2 warnings are completely useless, we should either remove the option to build a W=2 kernel or remove some of the warning flags that go into it. My feeling is that both W=2 in general, and the Wtype-limits have some value, and that reducing the number of W=2 by 30% as this patch does is a useful goal by itself. A different question is whether this particular patch is the best workaround for the warnings, or if a nicer alternative can be found, such as moving -Wtype-limits to W=3, or using an open-coded variant of __is_constexpr() that includes the comparison in a way that avoids the warning. Arnd