From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD0DAC43331 for ; Fri, 6 Sep 2019 03:16:03 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D241520674 for ; Fri, 6 Sep 2019 03:16:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="P3OC5Vjp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D241520674 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=YnAYIHkyvzsY/FvzCSwNcBqxNX7igcKFpGP5K4ejp8U=; b=P3OC5Vjpawaazm ichIvMkAzcXs2T79IIYlO78QHzTyx9HbeqONN8fv8V0L4MtUxPEk5nqSsNQrx7PgE2XN6Pgm7YY/t hXicQWDnb8PyIruBrWoL0ajL+TKUO6H4iFbPWa+AwedGg918uNkLoCDR2VZxdcYftciSEyNzgPAaA q45+n+V0LYNOrx0wx2h9jKs4afqx11wRPx4nMkqgfECTA+eCM873TnFlRsXLLf3TUmvAtj1UTa4HB fRhZkN7GoOgYUJSsWN/NKaQLHWGNvog0xP75wQjBxUTFJEbK8I2wS7/c98O50mCcTqQXo4DQhO1oZ Dnr+Ltf9IEcOyylDLldw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i64j5-0006Le-3h; Fri, 06 Sep 2019 03:15:55 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1i64iz-0006K2-44; Fri, 06 Sep 2019 03:15:51 +0000 X-UUID: a5dd2dac813441cbae60d8f4dbe77513-20190905 X-UUID: a5dd2dac813441cbae60d8f4dbe77513-20190905 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 1409498161; Thu, 05 Sep 2019 19:15:34 -0800 Received: from MTKMBS07N2.mediatek.inc (172.21.101.141) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 5 Sep 2019 20:15:32 -0700 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs07n2.mediatek.inc (172.21.101.141) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 6 Sep 2019 11:15:31 +0800 Received: from [172.21.84.99] (172.21.84.99) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Fri, 6 Sep 2019 11:15:31 +0800 Message-ID: <1567739734.32522.67.camel@mtksdccf07> Subject: Re: [PATCH 1/2] mm/kasan: dump alloc/free stack for page allocator From: Walter Wu To: Vlastimil Babka Date: Fri, 6 Sep 2019 11:15:34 +0800 In-Reply-To: <99913463-0e2c-7dab-c1eb-8b9e149b3ee3@suse.cz> References: <20190904065133.20268-1-walter-zh.wu@mediatek.com> <401064ae-279d-bef3-a8d5-0fe155d0886d@suse.cz> <1567605965.32522.14.camel@mtksdccf07> <7998e8f1-e5e2-da84-ea1f-33e696015dce@suse.cz> <1567607063.32522.24.camel@mtksdccf07> <99913463-0e2c-7dab-c1eb-8b9e149b3ee3@suse.cz> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190905_201549_168014_D8F2F66C X-CRM114-Status: GOOD ( 16.57 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: wsd_upstream@mediatek.com, Arnd Bergmann , linux-mm@kvack.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Martin Schwidefsky , Alexander Potapenko , linux-arm-kernel@lists.infradead.org, Matthias Brugger , Andrey Ryabinin , Andrew Morton , Dmitry Vyukov Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 2019-09-05 at 10:03 +0200, Vlastimil Babka wrote: > On 9/4/19 4:24 PM, Walter Wu wrote: > > On Wed, 2019-09-04 at 16:13 +0200, Vlastimil Babka wrote: > >> On 9/4/19 4:06 PM, Walter Wu wrote: > >> > >> The THP fix is not required for the rest of the series, it was even merged to > >> mainline separately. > >> > >>> And It looks like something is different, because we only need last > >>> stack of page, so it can decrease memory overhead. > >> > >> That would save you depot_stack_handle_t (which is u32) per page. I guess that's > >> nothing compared to KASAN overhead? > >> > > If we can use less memory, we can achieve what we want. Why not? > > In my experience to solve some UAFs, it's important to know not only the > freeing stack, but also the allocating stack. Do they make sense together, > or not? In some cases, even longer history of alloc/free would be nice :) > We think it only has free stack to find out the root cause. Maybe we can refer to other people's experience and ideas. > Also by simply recording the free stack in the existing depot handle, > you might confuse existing page_owner file consumers, who won't know > that this is a freeing stack. > Don't worry it. 1. Our feature option has this description about last stack of page. when consumer enable our feature, they should know the changing. 2. We add to print text message for alloc or free stack before dump the stack of page. so consumers should know what is it. > All that just doesn't seem to justify saving an u32 per page. Actually, We want to slim memory usage instead of increasing the memory usage at another mail discussion. Maybe, maintainer or reviewer can provide some ideas. That will be great. > > > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel