Messages in this thread | | | From | Geert Uytterhoeven <> | Date | Wed, 26 Jan 2022 13:37:45 +0100 | Subject | Re: kisskb: FAILED linux-next/m68k-allmodconfig/m68k-gcc8 Tue Jan 25, 18:24 |
| |
Hi Arnd,
On Wed, Jan 26, 2022 at 1:26 PM Arnd Bergmann <arnd@arndb.de> 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? > > 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.
Indeed, size matters not here.
> 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.
Thanks for investigating! So let's ignore this.
FTR, my gcc-9 is 9.4.0, i.e. >= 9.2.
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
| |