Received-SPF: pass (google.com: domain of linux-kernel+bounces-195759-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <b6632140-f2b0-40db-9d1e-2486ddc5810b@arm.com>
Date: Thu, 30 May 2024 18:50:59 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH net-next v6 13/21] bitmap: make bitmap_{get,set}_value8()
 use bitmap_{read,write}()
To: Yury Norov <yury.norov@gmail.com>
Cc: Alexander Lobakin <aleksander.lobakin@intel.com>,
 "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>,
 Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
 Alexander Potapenko <glider@google.com>,
 nex.sw.ncis.osdt.itp.upstreaming@intel.com,
 intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
 linux-kernel@vger.kernel.org
References: <20240327152358.2368467-1-aleksander.lobakin@intel.com>
 <20240327152358.2368467-14-aleksander.lobakin@intel.com>
 <5a18f5ac-4e9a-4baf-b720-98eac7b6792f@arm.com>
 <ZlizL6d1_ePq-eKs@yury-ThinkPad>
From: Robin Murphy <robin.murphy@arm.com>
Content-Language: en-GB
In-Reply-To: <ZlizL6d1_ePq-eKs@yury-ThinkPad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 30/05/2024 6:11 pm, Yury Norov wrote:
> On Wed, May 29, 2024 at 04:12:25PM +0100, Robin Murphy wrote:
>> Hi Alexander,
>>
>> On 27/03/2024 3:23 pm, Alexander Lobakin wrote:
>>> Now that we have generic bitmap_read() and bitmap_write(), which are
>>> inline and try to take care of non-bound-crossing and aligned cases
>>> to keep them optimized, collapse bitmap_{get,set}_value8() into
>>> simple wrappers around the former ones.
>>> bloat-o-meter shows no difference in vmlinux and -2 bytes for
>>> gpio-pca953x.ko, which says the optimization didn't suffer due to
>>> that change. The converted helpers have the value width embedded
>>> and always compile-time constant and that helps a lot.
>>
>> This change appears to have introduced a build failure for me on arm64
>> (with GCC 9.4.0 from Ubuntu 20.04.02) - reverting b44759705f7d makes
>> these errors go away again:
>>
>> In file included from drivers/gpio/gpio-pca953x.c:12:
>> drivers/gpio/gpio-pca953x.c: In function ‘pca953x_probe’:
>> ./include/linux/bitmap.h:799:17: error: array subscript [1, 1024] is outside array bounds of ‘long unsigned int[1]’ [-Werror=array-bounds]
>>    799 |  map[index + 1] &= BITMAP_FIRST_WORD_MASK(start + nbits);
>>        |                 ^~
>> In file included from ./include/linux/atomic.h:5,
>>                   from drivers/gpio/gpio-pca953x.c:11:
>> drivers/gpio/gpio-pca953x.c:1015:17: note: while referencing ‘val’
>>   1015 |  DECLARE_BITMAP(val, MAX_LINE);
>>        |                 ^~~
>> ./include/linux/types.h:11:16: note: in definition of macro ‘DECLARE_BITMAP’
>>     11 |  unsigned long name[BITS_TO_LONGS(bits)]
>>        |                ^~~~
>> In file included from drivers/gpio/gpio-pca953x.c:12:
>> ./include/linux/bitmap.h:800:17: error: array subscript [1, 1024] is outside array bounds of ‘long unsigned int[1]’ [-Werror=array-bounds]
>>    800 |  map[index + 1] |= (value >> space);
>>        |  ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
>> In file included from ./include/linux/atomic.h:5,
>>                   from drivers/gpio/gpio-pca953x.c:11:
>> drivers/gpio/gpio-pca953x.c:1015:17: note: while referencing ‘val’
>>   1015 |  DECLARE_BITMAP(val, MAX_LINE);
>>        |                 ^~~
>> ./include/linux/types.h:11:16: note: in definition of macro ‘DECLARE_BITMAP’
>>     11 |  unsigned long name[BITS_TO_LONGS(bits)]
>>        |                ^~~~
>>
>> I've not dug further since I don't have any interest in the pca953x
>> driver - it just happened to be enabled in my config, so for now I've
>> turned it off. However I couldn't obviously see any other reports of
>> this, so here it is.
> 
> It's a compiler false-positive. The straightforward fix is to disable the warning
> For gcc9+, and it's in Andrew Morton's tree alrady. but there's some discussion
> ongoing on how it should be mitigated properlu:
> 
> https://lore.kernel.org/all/0ab2702f-8245-4f02-beb7-dcc7d79d5416@app.fastmail.com/T/

Ah, great! Guess I really should have scrolled further down my lore 
search results - I assumed I was looking for any other reports of a 
recent regression in mainline, not ones from 6 months ago :)

Cheers,
Robin.