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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 411ABC388F7 for ; Mon, 9 Nov 2020 14:42:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 016DC206E3 for ; Mon, 9 Nov 2020 14:42:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604932932; bh=sqs6Ab6qmHb8wLjpO8+s17ibG0cExkZUhwdEEn/31RM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=GoNtyYh368AdQt0+3qf248GiGyKcU0wdCSvsUcUtdqlNHhDanT4PnQ3HA0RNFf5zJ zboE7Od8JkNTNQhTauFTR/+MRcVxYFrHEW3UutntksER1UfDgdC1xTWpju6YmjESMX FX0qy2ZaM8Kkbt15KjM+dCwIQ4g7TUlvIgeVsqaU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731493AbgKIOmL (ORCPT ); Mon, 9 Nov 2020 09:42:11 -0500 Received: from mail.kernel.org ([198.145.29.99]:56832 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731491AbgKIOmL (ORCPT ); Mon, 9 Nov 2020 09:42:11 -0500 Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com [209.85.210.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5132B221E9; Mon, 9 Nov 2020 14:42:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604932930; bh=sqs6Ab6qmHb8wLjpO8+s17ibG0cExkZUhwdEEn/31RM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=I0iWJXq7f8C4w8yCYfE3FJzyDJQWdci2e2Yo5BRR9N1qSpD90kCXxUr//h8p5d63l +zV4WPLmIRHHsTCfNzdRO/HdzzXaIZ7PKpQ76S7Yf4QyvazXUtPDly4j26hIe08QP8 KbhJeRUpCqLE2tWq83v7JaAVW9L0uqPr3XV6+Kmk= Received: by mail-ot1-f48.google.com with SMTP id j14so9125993ots.1; Mon, 09 Nov 2020 06:42:10 -0800 (PST) X-Gm-Message-State: AOAM5331pGgHLlj7FzCqTxsUz1K5+Xs/9kzQx7QHfnWclOREc6+xkhEH O/aKcGAdyUbj6Mt3JV177qp1JSvSjBGlGXb4860= X-Google-Smtp-Source: ABdhPJzeeo6JiBdT3OYlZsQwt9pc+G9cyqIJAbkyOtDcxvKwYR4vZ799vC2P3NypOkrxzEQQr00gdSY/oBLDecIaZeM= X-Received: by 2002:a05:6830:22d2:: with SMTP id q18mr9636879otc.305.1604932929586; Mon, 09 Nov 2020 06:42:09 -0800 (PST) MIME-Version: 1.0 References: <15a044d3ba23f00c31fd09437bdd3e5924bb91cd.1603055402.git.syednwaris@gmail.com> <20201101150033.GA68138@shinobu> <20201109123411.GA19869@syed> <20201109134128.GA5596@shinobu> In-Reply-To: <20201109134128.GA5596@shinobu> From: Arnd Bergmann Date: Mon, 9 Nov 2020 15:41:53 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v12 4/4] gpio: xilinx: Utilize generic bitmap_get_value and _set_value To: William Breathitt Gray Cc: Syed Nayyar Waris , Linus Walleij , Andrew Morton , "open list:GPIO SUBSYSTEM" , "linux-kernel@vger.kernel.org" , Michal Simek , Bartosz Golaszewski , Andy Shevchenko , Linux ARM Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Mon, Nov 9, 2020 at 2:41 PM William Breathitt Gray wrote: > On Mon, Nov 09, 2020 at 06:04:11PM +0530, Syed Nayyar Waris wrote: > > One of my concerns is that we're incurring the latency two additional > conditional checks just to suppress a compiler warning about a case that > wouldn't occur in the actual use of bitmap_set_value(). I'm hoping > there's a way for us to suppress these warnings without adding onto the > latency of this function; given that bitmap_set_value() is intended to > be used in loops, conditionals here could significantly increase latency > in drivers. At least for this caller, the size check would be a compile-time constant that can be eliminated. > I wonder if array_index_nospec() might have the side effect of > suppressing these warnings for us. For example, would this work: > > static inline void bitmap_set_value(unsigned long *map, > unsigned long value, > unsigned long start, unsigned long nbits) > { > const unsigned long offset = start % BITS_PER_LONG; > const unsigned long ceiling = round_up(start + 1, BITS_PER_LONG); > const unsigned long space = ceiling - start; > size_t index = BIT_WORD(start); > > value &= GENMASK(nbits - 1, 0); > > if (space >= nbits) { > index = array_index_nospec(index, index + 1); > > map[index] &= ~(GENMASK(nbits - 1, 0) << offset); > map[index] |= value << offset; > } else { > index = array_index_nospec(index, index + 2); > > map[index + 0] &= ~BITMAP_FIRST_WORD_MASK(start); > map[index + 0] |= value << offset; > map[index + 1] &= ~BITMAP_LAST_WORD_MASK(start + nbits); > map[index + 1] |= value >> space; > } > } > > Or is this going to produce the same warning because we're not using an > explicit check against the map array size? https://godbolt.org/z/fxnsG9 It still warns about the 'map[index + 1]' access: from all I can tell, gcc mainly complains because it cannot rule out that 'space < nbits', and then it knows the size of 'DECLARE_BITMAP(old, 64)' and finds that if 'index + 0' is correct, then 'index + 1' overflows that array. Arnd 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 349DBC2D0A3 for ; Mon, 9 Nov 2020 14:42:41 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D341D2074F for ; Mon, 9 Nov 2020 14:42:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="1v88som9"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="I0iWJXq7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D341D2074F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=iE9+dV7HkKsuDWvGIkqpNE8wpGnTeFce7pbt+D8CrFs=; b=1v88som93Z5YqS0HgZ6vp36ra CrRe7pkig1ZC4zdcotxW4TCj36jwSqgPNHiqSTJjRX0Z9V52m8M7J6H+pFZzcibDKeo0FDL08KeKW EsyIAGrfghQTs1mWBTDzcAQJQ0xlgSUlcSnSay3D0Z/09oWryIhqc/6U/Hb5gbw8eeLw1tQzzptym wpZwYvc14GRBLPAhA0mdHPOe05ZKPBr8m8nin5fCBleL1EpTqE6hJJkVFI8zFHwNtfJ5NKWc6Edyp y6HP9d8rgX0494lNLEHAPjfeId/cScu7PzgxcGfZ1mEVjEuD64+eiYV++q8b7AHXyE6CyhjTCZ135 R7JBMS9Jw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kc8N5-0006Uz-3L; Mon, 09 Nov 2020 14:42:15 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kc8N1-0006TZ-3Z for linux-arm-kernel@lists.infradead.org; Mon, 09 Nov 2020 14:42:12 +0000 Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4CE3C20E65 for ; Mon, 9 Nov 2020 14:42:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604932930; bh=sqs6Ab6qmHb8wLjpO8+s17ibG0cExkZUhwdEEn/31RM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=I0iWJXq7f8C4w8yCYfE3FJzyDJQWdci2e2Yo5BRR9N1qSpD90kCXxUr//h8p5d63l +zV4WPLmIRHHsTCfNzdRO/HdzzXaIZ7PKpQ76S7Yf4QyvazXUtPDly4j26hIe08QP8 KbhJeRUpCqLE2tWq83v7JaAVW9L0uqPr3XV6+Kmk= Received: by mail-ot1-f41.google.com with SMTP id 32so9125317otm.3 for ; Mon, 09 Nov 2020 06:42:10 -0800 (PST) X-Gm-Message-State: AOAM531jhhZbnZKrdLgBMSYrUP8IYfeJsjKCUtPvAEhL5VxJ9toaTiTH Nv+hanJe/F1rPV7YxZmywYHr+XH09CseSAwDGus= X-Google-Smtp-Source: ABdhPJzeeo6JiBdT3OYlZsQwt9pc+G9cyqIJAbkyOtDcxvKwYR4vZ799vC2P3NypOkrxzEQQr00gdSY/oBLDecIaZeM= X-Received: by 2002:a05:6830:22d2:: with SMTP id q18mr9636879otc.305.1604932929586; Mon, 09 Nov 2020 06:42:09 -0800 (PST) MIME-Version: 1.0 References: <15a044d3ba23f00c31fd09437bdd3e5924bb91cd.1603055402.git.syednwaris@gmail.com> <20201101150033.GA68138@shinobu> <20201109123411.GA19869@syed> <20201109134128.GA5596@shinobu> In-Reply-To: <20201109134128.GA5596@shinobu> From: Arnd Bergmann Date: Mon, 9 Nov 2020 15:41:53 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v12 4/4] gpio: xilinx: Utilize generic bitmap_get_value and _set_value To: William Breathitt Gray X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201109_094211_363339_83804D16 X-CRM114-Status: GOOD ( 23.75 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Bartosz Golaszewski , Linus Walleij , Michal Simek , "linux-kernel@vger.kernel.org" , "open list:GPIO SUBSYSTEM" , Andrew Morton , Andy Shevchenko , Syed Nayyar Waris , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Nov 9, 2020 at 2:41 PM William Breathitt Gray wrote: > On Mon, Nov 09, 2020 at 06:04:11PM +0530, Syed Nayyar Waris wrote: > > One of my concerns is that we're incurring the latency two additional > conditional checks just to suppress a compiler warning about a case that > wouldn't occur in the actual use of bitmap_set_value(). I'm hoping > there's a way for us to suppress these warnings without adding onto the > latency of this function; given that bitmap_set_value() is intended to > be used in loops, conditionals here could significantly increase latency > in drivers. At least for this caller, the size check would be a compile-time constant that can be eliminated. > I wonder if array_index_nospec() might have the side effect of > suppressing these warnings for us. For example, would this work: > > static inline void bitmap_set_value(unsigned long *map, > unsigned long value, > unsigned long start, unsigned long nbits) > { > const unsigned long offset = start % BITS_PER_LONG; > const unsigned long ceiling = round_up(start + 1, BITS_PER_LONG); > const unsigned long space = ceiling - start; > size_t index = BIT_WORD(start); > > value &= GENMASK(nbits - 1, 0); > > if (space >= nbits) { > index = array_index_nospec(index, index + 1); > > map[index] &= ~(GENMASK(nbits - 1, 0) << offset); > map[index] |= value << offset; > } else { > index = array_index_nospec(index, index + 2); > > map[index + 0] &= ~BITMAP_FIRST_WORD_MASK(start); > map[index + 0] |= value << offset; > map[index + 1] &= ~BITMAP_LAST_WORD_MASK(start + nbits); > map[index + 1] |= value >> space; > } > } > > Or is this going to produce the same warning because we're not using an > explicit check against the map array size? https://godbolt.org/z/fxnsG9 It still warns about the 'map[index + 1]' access: from all I can tell, gcc mainly complains because it cannot rule out that 'space < nbits', and then it knows the size of 'DECLARE_BITMAP(old, 64)' and finds that if 'index + 0' is correct, then 'index + 1' overflows that array. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel