Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp741238ybe; Wed, 4 Sep 2019 07:07:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqw4xZXhIFf/nbgK9rSChD34ILgmHlQZI9cer7fM3e84JJsvZanHNe8UmIQohacVLTv1SHyD X-Received: by 2002:a17:902:7c91:: with SMTP id y17mr22556989pll.46.1567606050942; Wed, 04 Sep 2019 07:07:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567606050; cv=none; d=google.com; s=arc-20160816; b=RU3AnNxvHtgb8uEVjKZdOwyCOqEkfp79Gndo7zAkKRzmrWW1uXTkLEI/3cZw1+gHEM dxe48rNJG5FlzSviO/m3H0VSac+UhMFODBCYN/1Mc/DT+LDJI16uFNRsB6uOOYWl8l/M gNpRvgPK/cEI3LvLsdySLMq1O6ovOZutXrkuCPYf63sDtChYIIg7ZIGDTC9WlsANVwlE fuJDEnV95O8yhAtIUmnkXMKH4cLvFVnuZYH6QM5ySmmRl+/H8mjxrDrw6BvPQ3cU3jr3 aD0ok91RNB0GEfhp7PflG/TVwKy734C1+G2PHLVCt7LnswSLc52bHenMfZBdYP7CF4Qs PVpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :references:in-reply-to:date:cc:to:from:subject:message-id; bh=IuDKnoKMd0F9fvFaFVZc+Lwcanh2TGjIEnM1OccvSgU=; b=MglkSrDKAkETRVlLP1iacp+ODQvXt5L1bX2C8OPEb6UZsr/F21+DSVfxF7R04KC6Fu IgInioRfnZtbxDuRlo/PUAOctY6oeAcpB2KXw78sfR85CLv84Fb6pcFFrTW1R7O2KA7n DNnBwhbvV7yJqttx2BlV9+FEc6QIiYUIzrP0NAE7CIIAUxjdwXnBNcJ93mUUnc684IHd iOmo/NKRm0n3l4SFCqZ8OlxWXiOfBj5iq3/nSuS/kGGZdaEKYCnVMJbd0vQaP6QP4EjE aGiS6jj3oPQHUcIJI5Tkxsw2sFMCS/YupfWUgNrC72dmhJFsUZF1BAx/YlIevTp/ENb1 Kddw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mediatek.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r3si17412834plb.215.2019.09.04.07.07.14; Wed, 04 Sep 2019 07:07:30 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mediatek.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730572AbfIDOGN (ORCPT + 99 others); Wed, 4 Sep 2019 10:06:13 -0400 Received: from mailgw01.mediatek.com ([210.61.82.183]:44382 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1730462AbfIDOGM (ORCPT ); Wed, 4 Sep 2019 10:06:12 -0400 X-UUID: f362c8a6c104411aa10ef7ebe1987d5b-20190904 X-UUID: f362c8a6c104411aa10ef7ebe1987d5b-20190904 Received: from mtkexhb02.mediatek.inc [(172.21.101.103)] by mailgw01.mediatek.com (envelope-from ) (Cellopoint E-mail Firewall v4.1.10 Build 0809 with TLS) with ESMTP id 2107079500; Wed, 04 Sep 2019 22:06:06 +0800 Received: from mtkcas09.mediatek.inc (172.21.101.178) by mtkmbs07n1.mediatek.inc (172.21.101.16) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 4 Sep 2019 22:06:05 +0800 Received: from [172.21.84.99] (172.21.84.99) by mtkcas09.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Wed, 4 Sep 2019 22:06:04 +0800 Message-ID: <1567605965.32522.14.camel@mtksdccf07> Subject: Re: [PATCH 1/2] mm/kasan: dump alloc/free stack for page allocator From: Walter Wu To: Vlastimil Babka CC: Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Matthias Brugger , Andrew Morton , "Martin Schwidefsky" , Arnd Bergmann , , , , , , Date: Wed, 4 Sep 2019 22:06:05 +0800 In-Reply-To: <401064ae-279d-bef3-a8d5-0fe155d0886d@suse.cz> References: <20190904065133.20268-1-walter-zh.wu@mediatek.com> <401064ae-279d-bef3-a8d5-0fe155d0886d@suse.cz> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2019-09-04 at 14:49 +0200, Vlastimil Babka wrote: > On 9/4/19 8:51 AM, Walter Wu wrote: > > This patch is KASAN report adds the alloc/free stacks for page allocator > > in order to help programmer to see memory corruption caused by page. > > > > By default, KASAN doesn't record alloc/free stack for page allocator. > > It is difficult to fix up page use-after-free issue. > > > > This feature depends on page owner to record the last stack of pages. > > It is very helpful for solving the page use-after-free or out-of-bound. > > > > KASAN report will show the last stack of page, it may be: > > a) If page is in-use state, then it prints alloc stack. > > It is useful to fix up page out-of-bound issue. > > I expect this will conflict both in syntax and semantics with my series [1] that > adds the freeing stack to page_owner when used together with debug_pagealloc, > and it's now in mmotm. Glad others see the need as well :) Perhaps you could > review the series, see if it fulfils your usecase (AFAICS the series should be a > superset, by storing both stacks at once), and perhaps either make KASAN enable > debug_pagealloc, or turn KASAN into an alternative enabler of the functionality > there? > > Thanks, Vlastimil > > [1] https://lore.kernel.org/linux-mm/20190820131828.22684-1-vbabka@suse.cz/t/#u > Thanks your information. We focus on the smartphone, so it doesn't enable CONFIG_TRANSPARENT_HUGEPAGE, Is it invalid for our usecase? And It looks like something is different, because we only need last stack of page, so it can decrease memory overhead. I will try to enable debug_pagealloc(with your patch) and KASAN, then we see the result. Thanks. Walter