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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2486C433FE for ; Tue, 15 Mar 2022 18:56:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245620AbiCOS5m (ORCPT ); Tue, 15 Mar 2022 14:57:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233823AbiCOS5k (ORCPT ); Tue, 15 Mar 2022 14:57:40 -0400 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 04D714E393; Tue, 15 Mar 2022 11:56:27 -0700 (PDT) Received: by mail-qt1-f172.google.com with SMTP id 11so2931qtt.9; Tue, 15 Mar 2022 11:56:26 -0700 (PDT) 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=x1R6MexnAYDRxJBUb0QgsDJ7MygsbxDZQB18nTdrN9k=; b=zsKLQZVmMlABXEa4cZ2YMoJAGJVQ673L6ghBnwPWKtAL+GwsEts0zqp9R164LRxKcx KydyC9yZfvnhbaPgstS1tHeyX9cWM0Z5ZDDKup6sDEYdFxZP6cpO/5SQF/0x94qSY81a WPE60yp2S2uLwqKiOMYSNXKtZUq8alqlYgzeLKuMRU55WW7RZpivZ47GJTwt+ib8+FII zE1VoHAZ0dhv0ArCxiWkjx1LywikG4tg9c7sgKbZN339oLow9aeyxUvp2ArTdASEeTpC 5gyseyGCZF7EddIsjzLhJycIMGDyyLiOXmtDUZnXHzgCVXqDtDmsEbtU4QZgc/lLz3tG 5Y7A== X-Gm-Message-State: AOAM532ulcFFpic5uaZRguyjwSq8yRfvOzXUJTqlMF0kH+dcHrrXTFoS NjGAHE11z7yVpkxpMIfyCVkIPak5oT5+HQ== X-Google-Smtp-Source: ABdhPJzm94DKiM/MVYEHZOrTxKXpLow5k0BvpABrrV9RCaueeaHtasWKDreg/aRQIjvHq0YXKEqfHg== X-Received: by 2002:ac8:5c90:0:b0:2de:37cd:8af6 with SMTP id r16-20020ac85c90000000b002de37cd8af6mr23372119qta.437.1647370586013; Tue, 15 Mar 2022 11:56:26 -0700 (PDT) Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com. [209.85.219.172]) by smtp.gmail.com with ESMTPSA id a13-20020a05622a064d00b002e1b8d9d6cfsm10246974qtb.32.2022.03.15.11.56.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Mar 2022 11:56:25 -0700 (PDT) Received: by mail-yb1-f172.google.com with SMTP id y142so275695ybe.11; Tue, 15 Mar 2022 11:56:25 -0700 (PDT) X-Received: by 2002:a25:aa0e:0:b0:633:7c3b:94a0 with SMTP id s14-20020a25aa0e000000b006337c3b94a0mr3416103ybi.546.1647370585424; Tue, 15 Mar 2022 11:56:25 -0700 (PDT) MIME-Version: 1.0 References: <20220310121327.63C6FC340E8@smtp.kernel.org> In-Reply-To: From: Geert Uytterhoeven Date: Tue, 15 Mar 2022 19:56:13 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL] SPI fixes for v5.17-rc7 To: Linus Torvalds Cc: Mark Brown , linux-spi , Linux Kernel Mailing List , Biju Das Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Linus, On Tue, Mar 15, 2022 at 5:48 PM Linus Torvalds wrote: > 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. You're absolutely right. So the code should be changed to: if (vmalloced_buf || kmap_buf) { - desc_len = min_t(unsigned int, max_seg_size, PAGE_SIZE); + desc_len = min_t(unsigned long, max_seg_size, PAGE_SIZE); sgs = DIV_ROUND_UP(len + offset_in_page(buf), desc_len); } else if (virt_addr_valid(buf)) { - desc_len = min_t(unsigned int, max_seg_size, ctlr->max_dma_len); + desc_len = min_t(size_t, max_seg_size, ctlr->max_dma_len); sgs = DIV_ROUND_UP(len, desc_len); } else { return -EINVAL; } Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds