Received: by 2002:ac2:48a3:0:0:0:0:0 with SMTP id u3csp36854lfg; Tue, 8 Mar 2022 18:54:19 -0800 (PST) X-Google-Smtp-Source: ABdhPJxqA9vf/OpxGvtFbqtq7CeVYwYidxhfILel8E0yUy0dZQg0ApM5oAsVGyulyPjx/TC5p2Ki X-Received: by 2002:a17:902:bf07:b0:150:9b8a:a14f with SMTP id bi7-20020a170902bf0700b001509b8aa14fmr20726831plb.127.1646794458923; Tue, 08 Mar 2022 18:54:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646794458; cv=none; d=google.com; s=arc-20160816; b=duovbHMlKt3HkeXLIdxV2K3rZ56fSwKs04n5GC5w7cBwUEvQE1OT135eenan56vb5v xZWLRkMZ3RNJsLSJrqVFm+sCulM1UEHOoqQvSQgrSXNLVMF0066j6OR5jJskAkeHsDws +ZRUp3LkWj4nuaPRydNNCFQ74P/olBlvLt2QHw+tUmpqVnd+UO3RUVKTms4pv6DUlf1w PIn6fGnY5Mn/uk2aNVUxOuSpMgWGktLxN5IHlE0jYgASDbYck+2nG9EHzU/0tGBXCF0d 67XAejmezmCznXjD2RFbUIuHpHXv/kCI3kebN1MJt9bXHbPzjTHqBBelM8E+7bfpVwhs 0PbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=IjsnXLLnEX74IBymbvjZ9/m5xmUhbzbxWgl/SAZeRj0=; b=OlmpC7xgjk/OVXQn3nZo6W+kwjJT+XwF8kMcIGOx/AaTaZfLFDSH7SDwz8l4wK0hO0 m5yQV7IkJb/yUhb7QCpvaULKvzVxMI8KSAH+72L5s7nSGV55WUH2xxSannfstreozor8 i4c6WuKWOIfMyliB7tG4r9/VzI2l3Dfcwh7Z+v2Dk89DE52W7iRgwSO/IQjFoH25FWr0 0O+mvtFyD3/hC6+JQfMybd1zBJmmQywslMGHN5biaJ4ko0FUKJROFobK/OqOVdFxbUML i9P8VVTtUilhDIjTBClURNk6UHmn/SQ+IFcWqj3aaEn0C6j3Euo76Un5Ppb6wI+CrYl2 pBFQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id c18-20020aa78e12000000b004f6f713bfc9si534455pfr.100.2022.03.08.18.54.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Mar 2022 18:54:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 A9847E3390; Tue, 8 Mar 2022 18:23:38 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231557AbiCICY1 convert rfc822-to-8bit (ORCPT + 99 others); Tue, 8 Mar 2022 21:24:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231279AbiCICYZ (ORCPT ); Tue, 8 Mar 2022 21:24:25 -0500 Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 170F0E1B65; Tue, 8 Mar 2022 18:23:27 -0800 (PST) Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-2dbfe58670cso8316707b3.3; Tue, 08 Mar 2022 18:23:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vRqEX4jehGb8mpHAHZanSBhzpnb3IlnL81jQ2qWnd2E=; b=AgTQOJMBWm65wrlgk9F3vl0WIIVs6Ww7J4tQcKQpbJ4oO11NlpztuAdwAzxOrVOCET DRSCQ7MkASEWAgWWUxEmsxnSOdKwoXkNcs3wg0chqlcXUziMTW1hkvde8vrHuMTraSvm x7RNQU5CXUO0EP5OS1yvN6IvSyrH1MXD4thumq9Fb7Jh1IjTwGggquhPkwQ+f/3j2sJP aLBVrqah46iUjU36xtRKUgqv83KvoYi9Zcw0DkJMmIHIcwKVPQBMa2RWJRk2nyGZinIq Lr9rOA8+sScj6dNZQTkWQFUA1GxsLZPvbNhZNzPN9OwmXp9qbgFiFxBu9+jUtdDInA1l /0hA== X-Gm-Message-State: AOAM531lhpn0enYcXzo5JHBZbw3mXE5X42ceVg2uxpEZibYAB/ORTjwz aCHkSP66oPaVBJnR0mJWXoz2lBoL84B0msWFm7c= X-Received: by 2002:a0d:db09:0:b0:2dc:344f:7944 with SMTP id d9-20020a0ddb09000000b002dc344f7944mr15041695ywe.45.1646792606156; Tue, 08 Mar 2022 18:23:26 -0800 (PST) MIME-Version: 1.0 References: <20220304124416.1181029-1-mailhol.vincent@wanadoo.fr> <20220308141201.2343757-1-mailhol.vincent@wanadoo.fr> In-Reply-To: From: Vincent MAILHOL Date: Wed, 9 Mar 2022 11:23:15 +0900 Message-ID: Subject: Re: [PATCH v2] linux/bits.h: GENMASK_INPUT_CHECK: reduce W=2 noise by 31% treewide To: Linus Torvalds Cc: Rikard Falkeborn , Andrew Morton , Linux Kernel Mailing List , Arnd Bergmann , Andy Shevchenko , Kees Cook , Alexander Lobakin , Herbert Xu , Emil Velikov , Geert Uytterhoeven , Linus Walleij , linux-arch , kernel test robot , Syed Nayyar Waris , William Breathitt Gray , Masahiro Yamada Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT 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 Hi Linus, On Wed. 9 Mar 2022 at 03:13, Linus Torvalds wrote: > On Tue, Mar 8, 2022 at 6:12 AM Vincent Mailhol > wrote: > > > > This patch silences a -Wtypes-limits warning in GENMASK_INPUT_CHECK() > > which is accountable for 31% of all warnings when compiling with W=2. > > Please, just make the patch be "remote -Wtypes-limits". After this patch, the number of remaining -Wtype-limits drops by 99.7% from 164714 to only 431 for an allyesconfig (some of which could be true positives). So I am inclined to keep -Wtype-limits at W=2 because it still catches some relevant issues. Aside from the issue pointed out here, it is not a hindrance. > Instead of making an already complicated check more complicated, and > making it more fragile. ACK, this patch makes it more complicated. About making it more fragile, lib/test_bits.c is here to catch issues and this patch passes those tests including the TEST_GENMASK_FAILURES. > I don't see why that int cast on h would be valid, for example. Why > just h? The compiler only complains on ((unsigned int)foo > 0) patterns, i.e. when h is unsigned and l is zero. The signness of l is not relevant here. > And should you not then check that the cast doesn't actually > change the value? The loss of precision only occurs on big values e.g. GENMASK(UINT_MAX + 1, 0). GENMASK (and GENMASK_ULL) already requires h and l to be between 0 and 31 (or 63). Out of band positive values are caught by -Wshift-count-overflow (and negative values by -Wshift-count-negative). So the use cases in which the int cast would change h value are already caught elsewhere. > But the basic issue is that the compiler warns about bad things, and > the problem isn't the code, but the compiler. ACK, the code is not broken, the compiler is guilty. I tend to agree to the rule "if not broken, don’t fix", but I consider this patch to be *the exception* because of the outstanding level of noise generated here. If my message did not convince you, then I am fine to move -Wtypes-limits from W=2 to W=3 as a compromise. But this is not my preferred solution because some -Wtypes-limits warnings are useful. Yours sincerely, Vincent Mailhol