Messages in this thread | | | Date | Wed, 26 Jan 2022 08:42:49 -0800 | From | Kees Cook <> | Subject | Re: kisskb: FAILED linux-next/m68k-allmodconfig/m68k-gcc8 Tue Jan 25, 18:24 |
| |
On Wed, Jan 26, 2022 at 01:25:45PM +0100, Arnd Bergmann wrote: > On Wed, Jan 26, 2022 at 10:16 AM Geert Uytterhoeven > <geert@linux-m68k.org> wrote: > > On Wed, Jan 26, 2022 at 9:54 AM Kees Cook <keescook@chromium.org> wrote: > > > >> > > > >> The code that causes this is drivers/net/ipa/ipa_mem.c:ipa_mem_valid(): > > > >> > > > >> DECLARE_BITMAP(regions, IPA_MEM_COUNT) = { }; > > > >> ... > > > >> for_each_clear_bit(mem_id, regions, IPA_MEM_COUNT) { > > > >> if (ipa_mem_id_required(ipa, mem_id)) > > > >> dev_err(dev, "required memory region %u missing\n", > > > >> mem_id); > > > >> } > > > >> > > > >> This only happens with gcc-8, not with gcc-9, so it might be a > > > >> compiler bug. I don't see anything wrong with c:ipa_mem_valid() > > > >> nor with m68k's find_first_zero_bit(). > > > > > > > >I don't see any problems about how this code uses bitmap API. > > > >The m68k version of find_first_zero_bit() looks correct as well. > > > > > > The trouble is with "enum ipa_mem_id mem_id;" which is an int, and the bitmap API requires unsigned long. I tried to fix this[1] at the source, but the maintainers want each[2] call site to fix it instead. :( > > > > Sorry, I don't get it. "mem_id" is not used as the bitmap, "regions" is, > > and the latter has the correct type?
Oops, sorry, this looked so much like the other bitops stuff I thought that was the problem. You are right -- something else is going on.
> I think you are right here, and even if it was an array of 'unsigned > int' instead > of 'unsigned long', this should not change the size of the object on > a 32-bit architecture. > > I ran the preprocessed code through cvise[1], bisecting for a reduced > test case that fails on gcc-8 but succeeds on gcc-9. The reduced > case is still fairly complex, and it appears to only happen in the > presence of an inline asm. Narrowing down the compiler versions shows > that anything after gcc-9.2 does not warn, but 9.1 and earlier versions do, > which is further indication that it was probably a false-positive that got > fixed in gcc.
Eek. Can we work around it in this code, or should -Warray-bounds have a gcc version check?
-- Kees Cook
| |