Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp4200041ybi; Mon, 3 Jun 2019 07:13:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqzMwpZwbNjPABYes9enOf1Azm9Z6rPwZKKmJtLGs2KyqSiczkzykvpowhlBs0jK+c9Khidw X-Received: by 2002:a17:902:2a4a:: with SMTP id i68mr31309707plb.25.1559571235880; Mon, 03 Jun 2019 07:13:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559571235; cv=none; d=google.com; s=arc-20160816; b=tRks9UyA70Yx5UkgUk4aMsJ1ty/aEdH6PfBtSeiCG2TVCiMVy/WEPPyBLg8MPKFQXK YxyeusjgcuDSaEYyJCb3t8MfrEnUSS4kpvFdxWurXILJpVaDWHtSEit66/IvvCp4jQd4 ARFPRjmGsAEUL45Z1LPm1gqKsXgIMi3AK4vkqsbnpty1vFaZA6l/U8FRKXVxp2UqX/jw UXRQTV1VLUF7ioohZEQ9mv2f44cZ0xkllqsTIr3KmOoEbNJdtSyLoAP7sW5XTlwA8uiE 8fYf8ynoL4WlLcn71uMgRbwa4AwjYxpVqATcvkLa3uzAQOQG5Y8a6dQoFiRkIL63op7u 19Ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=aqr2nSKe8ekislLVigui3mzwW+3e9nhwTC7BWuQq3Pg=; b=p9hx/iXPDmS/5/neCeyjtumfla99U/8hR+0VQwjlr22E90ezDrC7vJN/mWNtuwtDV7 G5Zhcr/bOMTUUJauNCKv3cdm+/qRhI3ErsG6n6oytiBkrUTvdFBOOqKrYgIf+pXR4BMc vPBiRl/lUqhLBXcPljhELO2G/7LIowu/uDm7Eugav1nOfKC7knXhVxmKSaS6wdyLXSUI h4j6A7tUh/+q4oRG4qCBnnu7BemH61dWRU94+0rdIHCywS4WJyBt/F78Fwmh6Aft379B gfZVycdaVF+KzdBeS+LgZpQhZrB8+DVp4lOlwcxdzZXKTE+sHlhyiNiU5DMUBDFG1AZC u3wA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=mcwoSVCk; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r11si18584362pgp.232.2019.06.03.07.13.38; Mon, 03 Jun 2019 07:13:55 -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; dkim=pass header.i=@kernel.org header.s=default header.b=mcwoSVCk; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728748AbfFCOKz (ORCPT + 99 others); Mon, 3 Jun 2019 10:10:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:47056 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728400AbfFCOKz (ORCPT ); Mon, 3 Jun 2019 10:10:55 -0400 Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1EB9A27AD0; Mon, 3 Jun 2019 14:10:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559571054; bh=DTEl1S9/WHP6uuMXaF6ALTUCnTGHtBY7UQFPnpvsYUM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=mcwoSVCkk7LtwsFLg6jdfNP+o4HaywLn6eCcix9yDN0dSmR/7tEsIarkiW7pZ3EtG FgpyxaGwqfUdBNUpJUdxWsv9KDAevfo4zaG88QMmWowjI1rIiCYHwcaTJfouNezkfc LbkUhEViJ2XDHhnKldyJwDgVc1TpHb/G8Wl6nu5g= Received: by mail-lf1-f47.google.com with SMTP id r15so13705329lfm.11; Mon, 03 Jun 2019 07:10:54 -0700 (PDT) X-Gm-Message-State: APjAAAX0pivBcRIJ0RDDdrUYVibma8saAH3HGWsHpYmasUcYBGuZo7mf /dXfbgcGU5oWUSk89oAEnvqsTdiNCObaROonT/o= X-Received: by 2002:ac2:43c2:: with SMTP id u2mr781039lfl.159.1559571052305; Mon, 03 Jun 2019 07:10:52 -0700 (PDT) MIME-Version: 1.0 References: <20190603135939.e2mb7vkxp64qairr@pc636> In-Reply-To: <20190603135939.e2mb7vkxp64qairr@pc636> From: Krzysztof Kozlowski Date: Mon, 3 Jun 2019 16:10:40 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [BUG BISECT] bug mm/vmalloc.c:470 (mm/vmalloc.c: get rid of one single unlink_va() when merge) To: Uladzislau Rezki , Stephen Rothwell Cc: Andrew Morton , Michal Hocko , linux-mm@kvack.org, Marek Szyprowski , "linux-samsung-soc@vger.kernel.org" , linux-kernel@vger.kernel.org, Hillf Danton , Thomas Gleixner , Tejun Heo , Andrei Vagin Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 3 Jun 2019 at 15:59, Uladzislau Rezki wrote: > > Hello, Krzysztof. > > On Mon, Jun 03, 2019 at 11:07:46AM +0200, Krzysztof Kozlowski wrote: > > Hi, > > > > On recent next I see bugs during boot (after bringing up user-space or > > during reboot): > > kernel BUG at ../mm/vmalloc.c:470! > > On all my boards. On QEMU I see something similar, although the > > message is "Internal error: Oops - undefined instruction: 0 [#1] ARM", Indeed it looks like effect of merge conflict resolution or applying. When I look at MMOTS, it is the same as yours: http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/commit/?id=b77b8cce67f246109f9d87417a32cd38f0398f2f However in linux-next it is different. Stephen, any thoughts? Best regards, Krzysztof > > > > The calltrace is: > > [ 34.565126] [] (__free_vmap_area) from [] > > (__purge_vmap_area_lazy+0xd0/0x170) > > [ 34.573963] [] (__purge_vmap_area_lazy) from [] > > (_vm_unmap_aliases+0x1fc/0x244) > > [ 34.582974] [] (_vm_unmap_aliases) from [] > > (__vunmap+0x170/0x200) > > [ 34.590770] [] (__vunmap) from [] > > (do_free_init+0x40/0x5c) > > [ 34.597955] [] (do_free_init) from [] > > (process_one_work+0x228/0x810) > > [ 34.606018] [] (process_one_work) from [] > > (worker_thread+0x30/0x570) > > [ 34.614077] [] (worker_thread) from [] > > (kthread+0x134/0x164) > > [ 34.621438] [] (kthread) from [] > > (ret_from_fork+0x14/0x20) > > > > Full log here: > > https://krzk.eu/#/builders/1/builds/3356/steps/14/logs/serial0 > > https://krzk.eu/#/builders/22/builds/1118/steps/35/logs/serial0 > > > > Bisect pointed to: > > 728e0fbf263e3ed359c10cb13623390564102881 is the first bad commit > > commit 728e0fbf263e3ed359c10cb13623390564102881 > > Author: Uladzislau Rezki (Sony) > > Date: Sat Jun 1 12:20:19 2019 +1000 > > mm/vmalloc.c: get rid of one single unlink_va() when merge > > > I have checked the linux-next. I can confirm it happens because of: > mm/vmalloc.c: get rid of one single unlink_va() when merge > > The problem is that, it has been applied wrongly into linux-next tree > for some reason, i do not why. Probably due to the fact that i based > my work on 5.1/2-rcX, whereas linux-next is a bit ahead of it. If so, > sorry for that. > > See below the clean patch for remotes/linux-next/master: > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 650c89f38c1e..0ed95b864e31 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -719,9 +719,6 @@ merge_or_add_vmap_area(struct vmap_area *va, > /* Check and update the tree if needed. */ > augment_tree_propagate_from(sibling); > > - /* Remove this VA, it has been merged. */ > - unlink_va(va, root); > - > /* Free vmap_area object. */ > kmem_cache_free(vmap_area_cachep, va); > > @@ -746,12 +743,11 @@ merge_or_add_vmap_area(struct vmap_area *va, > /* Check and update the tree if needed. */ > augment_tree_propagate_from(sibling); > > - /* Remove this VA, it has been merged. */ > - unlink_va(va, root); > + if (merged) > + unlink_va(va, root); > > /* Free vmap_area object. */ > kmem_cache_free(vmap_area_cachep, va); > - > return; > } > } > -- > 2.11.0 > > > Andrew, i am not sure how to proceed with that. Should i send an updated series > based on linux-next tip or you can fix directly that patch? > > Thank you! > > -- > Vlad Rezki