linux-kernel - Re: [PATCH net-next v6 13/21] bitmap: make bitmap_{get,set}_value8() use bitmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Thu, 30 May 2024 18:50:59 +0100
From: Robin Murphy <robin.murphy@....com>
To: Yury Norov <yury.norov@...il.com>
Cc: Alexander Lobakin <aleksander.lobakin@...el.com>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Alexander Potapenko <glider@...gle.com>,
 nex.sw.ncis.osdt.itp.upstreaming@...el.com,
 intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v6 13/21] bitmap: make bitmap_{get,set}_value8()
 use bitmap_{read,write}()

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.