Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp262332pxp; Wed, 16 Mar 2022 05:26:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxgILuVQ44BMdbu8xcRx3npTcUG5yuFzQte/rixe19YqziEKPu18cY3lWKzrZt4JUEL+w8B X-Received: by 2002:a17:90a:9106:b0:1b9:115a:a2c1 with SMTP id k6-20020a17090a910600b001b9115aa2c1mr10056565pjo.80.1647433569383; Wed, 16 Mar 2022 05:26:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647433569; cv=none; d=google.com; s=arc-20160816; b=iEXm9puNYN14JJEhjzqK1a3tZmb3RgfkTNW9FYV3/EhKG8yKEA19id3+CEtl4W44cu yj6YpHa56Nxy4d2RdVE9+aRiuATq/HG9mhghbZ/bLVsn0zahCPsVnr566HP8FPTnCGJr oXlHizgxkgqYl0iGQzM0vFmU2dZof6Zq9lf+/9fZzZd3Y4uPqkPjYa76LmPGehg6XUnO K9FKSqIprdTZFkzEY/K1Zlgw0iZmYGYEPKLtbgQKFosPzu09SeZE/YhHJZ2NKYPbVz8Q C9LU+8lywdXSzj2IiABQ8W3s7UfVALO2hvw2J0e7kF9VG7MO630iLJMiOkcq2pb9XlEi U2kw== 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:dkim-signature; bh=zt/r5r2zHXpo2duxNnaYNgAPA5dxpfI76juAqVaexSw=; b=OFGuWag5HKPdbqLKoKpqGIOJT0MrssYwh0FZTLkNsYC8lAREt/peokLTjulrjZF9zq Yw49ivByDxWl8Ny6/9FclPYpm0kSW+aCdLmaQWGoBRJzZW3jqYgupmEvWQ5kCzXECqYe R86q6KvbyrbRdf+2gZN9a1HCyDKwyxrxwSLudby8LWDBEH0vCT8WINuC8pPsVjQ3uw0R EACz+sqByeLqFgSXGATSj00UbaJiLO1FsvV/gld0DJIoM1FUIF78ZaVHa+PH5FG5rfJx ecQ4IIfK6ijjMYSNKXrBizoDEdiUW4Hk/Kqxy6LAjJ2UqQaJ2j5+WYkpa2HmjnANpjJ5 pB/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=Y8ZdU+ny; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z5-20020a170903018500b00151cd6ee067si1679330plg.564.2022.03.16.05.25.54; Wed, 16 Mar 2022 05:26:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=Y8ZdU+ny; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350197AbiCOQt5 (ORCPT + 99 others); Tue, 15 Mar 2022 12:49:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54996 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350124AbiCOQty (ORCPT ); Tue, 15 Mar 2022 12:49:54 -0400 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D10F15715E for ; Tue, 15 Mar 2022 09:48:40 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id q5so27299277ljb.11 for ; Tue, 15 Mar 2022 09:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zt/r5r2zHXpo2duxNnaYNgAPA5dxpfI76juAqVaexSw=; b=Y8ZdU+nyxKNyEdgJPvaWFUnJeWVz2wDo7JAxJf0kQlI3siurpvUSwzZXG6ifa5fbmg MltEjmXOo5W/lLyp5KhMrgLIzMlNAy0/jeohNDmB9yR04no6Qu+KmI3XIpDHN31hjRkQ amVOlehEnYI4vI6vTRY9fPOaSRRx8KBdzOaJg= 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; bh=zt/r5r2zHXpo2duxNnaYNgAPA5dxpfI76juAqVaexSw=; b=Hvl95MPxlP1GD3Wq9fJdRLwri5JUpZ//xlGXKLVf7OTjhl79kOxqBDdBknf4/NlSqa 7Q0Dk6FYNCPyXh3wAfEt+hGdHD+SvGCRKKsWlI0dVyeVqM3NErvUSHx7sSEU/ts7Qt/E pZ7E6gbne+0aAD537AWsrVeRUVrGrTu3M6Ck3sr1dGrSuaWoD8m6abDpcbQH9GdE8VVs AI+ufy1ZMfCMlXlu57efsBv2RCQNbfS/px35ZLOa33Becz5icYjvHI2O+sGtNMmrSrid RGgvabP4iy86MCsMGmCJSOnMs1cGIfnLXJIo4XYAzPbzi6mDFrHXHMqBthWA2HO9KHya OFZw== X-Gm-Message-State: AOAM532m7rb6PLYEauYWo1FicLYmJjr695mrJZkH9eDfEnxTxwnUQXUY T0e/xg7/x/x/4ViBpWNveTsfVwWejbvEBtqT X-Received: by 2002:a2e:95c9:0:b0:248:a587:bc97 with SMTP id y9-20020a2e95c9000000b00248a587bc97mr16123703ljh.349.1647362917663; Tue, 15 Mar 2022 09:48:37 -0700 (PDT) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com. [209.85.208.174]) by smtp.gmail.com with ESMTPSA id z2-20020ac24f82000000b0044850790636sm3689969lfs.87.2022.03.15.09.48.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Mar 2022 09:48:36 -0700 (PDT) Received: by mail-lj1-f174.google.com with SMTP id u7so27273866ljk.13 for ; Tue, 15 Mar 2022 09:48:36 -0700 (PDT) X-Received: by 2002:a2e:804b:0:b0:247:e81f:87e9 with SMTP id p11-20020a2e804b000000b00247e81f87e9mr18220509ljg.176.1647362916222; Tue, 15 Mar 2022 09:48:36 -0700 (PDT) MIME-Version: 1.0 References: <20220310121327.63C6FC340E8@smtp.kernel.org> In-Reply-To: From: Linus Torvalds Date: Tue, 15 Mar 2022 09:48:19 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL] SPI fixes for v5.17-rc7 To: Geert Uytterhoeven Cc: Mark Brown , linux-spi , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 Tue, Mar 15, 2022 at 2:08 AM Geert Uytterhoeven wrote: > > I had noticed while reviewing the patch, but changing to size_t wouldn't > help much, as other related code paths treat the value as unsigned int > anyway. .. but it really would. Note that the paths *after* this code don't matter. Because the result is guaranteed to fit in 'unsigned int' anyway. Put another way: min_t(unsigned int,x,y) is buggy if one of x/y is 'size_t'. Why? Because if that one gets truncated, you're doing 'min()' with a value that may be artificially much too small (that was exactly the problem commit 1a4e53d2fc4f: "spi: Fix invalid sgs value")fixed). But the situation is _not_ true in the reverse. Look: min(size_t,x,y) is guaranteed to fit in 'unsigned int' as long as _one_ of x,y fits in 'unsigned int' - even if the other doesn't. Because then 'min()' will just pick the one that already had the right size. To make it really concrete, compare min_t(unsigned int, 5, 0x100000001); min_t(size_t, 5, 0x100000001); on a 64-bit machine (ie size_t is 64-bits, and unsigned int is 32-bit). One returns 1. The other returns 5. Both fit the result in 'unsigned int', but one of them is wrong. Linus