Messages in this thread | | | Date | Mon, 17 Jun 2019 16:50:17 +0200 | From | Roman Penyaev <> | Subject | Re: [BUG]: mm/vmalloc: uninitialized variable access in pcpu_get_vm_areas |
| |
On 2019-06-17 16:44, Arnd Bergmann wrote: > On Mon, Jun 17, 2019 at 4:12 PM Uladzislau Rezki <urezki@gmail.com> > wrote: >> >> On Mon, Jun 17, 2019 at 02:14:11PM +0200, Arnd Bergmann wrote: >> > gcc points out some obviously broken code in linux-next >> > >> > mm/vmalloc.c: In function 'pcpu_get_vm_areas': >> > mm/vmalloc.c:991:4: error: 'lva' may be used uninitialized in this function [-Werror=maybe-uninitialized] >> > insert_vmap_area_augment(lva, &va->rb_node, >> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > &free_vmap_area_root, &free_vmap_area_list); >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > mm/vmalloc.c:916:20: note: 'lva' was declared here >> > struct vmap_area *lva; >> > ^~~ >> > >> > Remove the obviously broken code. This is almost certainly >> > not the correct solution, but it's what I have applied locally >> > to get a clean build again. >> > >> > Please fix this properly. >> > > >> > >> Please do not apply this. It will just break everything. > > As I wrote in my description, this was purely meant as a bug > report, not a patch to be applied.
That's a perfect way to attract attention! :)
> >> As Roman pointed we can just set lva = NULL; in the beginning to make >> GCC happy. >> For some reason GCC decides that it can be used uninitialized, but >> that >> is not true. > > I got confused by the similarly named FL_FIT_TYPE/NE_FIT_TYPE
Names are indeed very confusing, that is true. Very easy to mix up things.
-- Roman
| |