Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp2556261ybi; Mon, 17 Jun 2019 06:50:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqyd5znOGE2l0tMBhZcv4nvXoIkU/pdBGwntWXCAwUEnidlBaLbBWk1qLXVdmzygePR6lsey X-Received: by 2002:a17:902:124:: with SMTP id 33mr47691782plb.145.1560779457213; Mon, 17 Jun 2019 06:50:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560779457; cv=none; d=google.com; s=arc-20160816; b=gpQH6ItE+5Se+6MkNV02ARQvJf82CsDvDQzfEF3NBWufPHWHaXoPb0R9UXQ0g8lrTu Gb4VsI9Jln90K3TwC+SIK4FsMGZIkNio6g9uclm2IFfIaeEbNEgwwfQj3nSFzSmpjlFi ssZpcmoYa7P1OwiyP66t2zb+/ss+RaalrGaMmdRavanR9Lh4+cmh/TWo/INddXbf44PP A8H/XYNHxEhYltF3fSKOuzQoXXB3G4megkFE4NIPZvft7jbPqHXZvCo7bsNzV/hS3JG9 jwELMcEoVRAKrhQdyHwU+bDaZJrhABu0uMKXbDkqIoP3GsMwl6VMxxSUt7wxKZqhbxQP iyrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version; bh=k8KJABV0pjaeSdu3eRzn39Bn+zaPpAMCsb34seUTEbE=; b=QH1J0+xuimmw75mtLqd6J+R0+niYv15sl4z4IFEojXw60kNrj2mLfnBBB2mDUW/ytT u6MPVGtGijs2J53g/+5/7rC1CCularDrkwx1u1wb4u4/3XPtfLBYYpHTAYmrpoN7McD8 Pq+gxOVmTcvhSlpAIV2gw9hzneuMDr82wkrSgvY5GSsamfooIkJpA/t3+vTPh95c/Yjp ASKHweROP5LnX3RUShs+vfB5WUIFv7K1ZRkLD6Y9linnhG/SDfaQelFn7Yr68CiF2PXm A0fAfE4vQQnm/M2DhmtQsSK9eNsMPWKvLq8k9A160vDfpJN6HNgHPVJy5zUHBmrel3XS Dlww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r12si9726194pjp.56.2019.06.17.06.50.41; Mon, 17 Jun 2019 06:50:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728036AbfFQNtz (ORCPT + 99 others); Mon, 17 Jun 2019 09:49:55 -0400 Received: from mx2.suse.de ([195.135.220.15]:41012 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725906AbfFQNtz (ORCPT ); Mon, 17 Jun 2019 09:49:55 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id BADC8AF30; Mon, 17 Jun 2019 13:49:53 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 17 Jun 2019 15:49:51 +0200 From: Roman Penyaev To: Arnd Bergmann Cc: "Uladzislau Rezki (Sony)" , Roman Gushchin , Michal Hocko , Matthew Wilcox , Thomas Garnier , Oleksiy Avramchenko , Steven Rostedt , Joel Fernandes , Thomas Gleixner , Ingo Molnar , Tejun Heo , Andrew Morton , Linus Torvalds , Stephen Rothwell , Rick Edgecombe , Andrey Ryabinin , Mike Rapoport , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [BUG]: mm/vmalloc: uninitialized variable access in pcpu_get_vm_areas In-Reply-To: <20190617121427.77565-1-arnd@arndb.de> References: <20190617121427.77565-1-arnd@arndb.de> Message-ID: <457d8e5e453a18faf358bc1360a19003@suse.de> X-Sender: rpenyaev@suse.de User-Agent: Roundcube Webmail Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-06-17 14:14, 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. > > Fixes: 68ad4a330433 ("mm/vmalloc.c: keep track of free blocks for vmap > allocation") > Signed-off-by: Arnd Bergmann > --- > mm/vmalloc.c | 7 +------ > 1 file changed, 1 insertion(+), 6 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index a9213fc3802d..bfcf0124a773 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -984,14 +984,9 @@ adjust_va_to_fit_type(struct vmap_area *va, > return -1; > } > > - if (type != FL_FIT_TYPE) { > + if (type == FL_FIT_TYPE) > augment_tree_propagate_from(va); > > - if (type == NE_FIT_TYPE) > - insert_vmap_area_augment(lva, &va->rb_node, > - &free_vmap_area_root, &free_vmap_area_list); > - } > - > return 0; > } Hi Arnd, Seems the proper fix is just setting lva to NULL. The only place where lva is allocated and then used is when type == NE_FIT_TYPE, so according to my shallow understanding of the code everything should be fine. -- Roman