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=-8.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=ham 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 BAA77C433E1 for ; Thu, 13 Aug 2020 12:26:25 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 839732078D for ; Thu, 13 Aug 2020 12:26:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="sAjOxNux"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="GmWMcG+B" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 839732078D 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-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.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=ngqCMVGLf7oeuJc98mXg0PCVcSPLlamHnAIrEyMInAk=; b=sAjOxNux/rEoYIDgnY3HLPAc2 iGcdK/4L6Hj7mEvJrqQ8Z42TivmwS/2QzZqnBSg/dx7+EyYn501w632rh+o+r42bf2YHQh9Ufh/Ov qMBuE7xTBZ42vYfO2soeiuabEy6rhsvwJ4Iw2FF9R49P/dHrJLNRUKmXX/h23ORSC9yJMvYhfW+eC ZRrkZCdMzxcufXT9WVKydeS6JZLs6QUWKCDqfWRCSlNLWaNCWrwPSYtzLCy58WVVA8gzYPJ56lQPo mB1BYDfZNWSDFbfb5Ma7UqhPyXtxuVpTAmjiIqhiMZ84ZqymkXsasz+VCo84BNuv6jX14uWJF1u4o ReukBB9dQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k6CJE-00013z-Ag; Thu, 13 Aug 2020 12:26:16 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k6CJ9-00012u-4f; Thu, 13 Aug 2020 12:26:12 +0000 X-UUID: 4056165f5dd74230a73c1333f3521aa4-20200813 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=e41c5oYHqFyVyE7RzGdj+2oNjx9zrZ3d7b52Xcy+lRI=; b=GmWMcG+BIBGO22uTdBbkrn4zxhcIScGQV8kNkFh3aoyvpEBcuhLidVJYbbOhI7ChlNj7U0MR6x8qdXG3THfdCkFhm7VpvhPJEMlezo1v5OQOoERcGV2c9B+IZGSLTcjzEh7wEH6hX8AF+hKfpd2LTpG5oADKtYgSGq3d9Cca9V0=; X-UUID: 4056165f5dd74230a73c1333f3521aa4-20200813 Received: from mtkcas67.mediatek.inc [(172.29.193.45)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 1124127630; Thu, 13 Aug 2020 04:26:06 -0800 Received: from MTKMBS01N2.mediatek.inc (172.21.101.79) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 05:26:02 -0700 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs01n2.mediatek.inc (172.21.101.79) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 20:25:54 +0800 Received: from [172.21.84.99] (172.21.84.99) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 13 Aug 2020 20:25:54 +0800 Message-ID: <1597321556.9999.27.camel@mtksdccf07> Subject: Re: [PATCH 1/5] timer: kasan: record and print timer stack From: Walter Wu To: Thomas Gleixner Date: Thu, 13 Aug 2020 20:25:56 +0800 In-Reply-To: <87d03ulqbp.fsf@nanos.tec.linutronix.de> References: <20200810072313.529-1-walter-zh.wu@mediatek.com> <87d03ulqbp.fsf@nanos.tec.linutronix.de> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-TM-SNTS-SMTP: 6EB2F04DEDD30544E1EE481F458926A2139F49991264C64715B53AF6C629549C2000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200813_082611_310021_831DFDFF X-CRM114-Status: GOOD ( 37.90 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: John Stultz , wsd_upstream , Stephen Boyd , linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, 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-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Thu, 2020-08-13 at 13:48 +0200, Thomas Gleixner wrote: > Walter, > > Walter Wu writes: > > This patch records the last two timer queueing stacks and prints > > "This patch" is useless information as we already know from the subject > line that this is a patch. > > git grep 'This patch' Documentation/process/ > Thanks for your information. > > up to 2 timer stacks in KASAN report. It is useful for programmers > > to solve use-after-free or double-free memory timer issues. > > > > When timer_setup() or timer_setup_on_stack() is called, then it > > prepares to use this timer and sets timer callback, we store > > this call stack in order to print it in KASAN report. > > we store nothing. Don't impersonate code please. > > Also please structure the changelog in a way that it's easy to > understand what this is about instead of telling first what the patch > does and then some half baken information why this is useful followed by > more information about what it does. > > Something like this: > > For analysing use after free or double free of objects it is helpful > to preserve usage history which potentially gives a hint about the > affected code. > > For timers it has turned out to be useful to record the stack trace > of the timer init call. > > Record the most recent two timer init calls in KASAN which are printed > on failure in the KASAN report. > > See, this gives a clear context, an explanation why it is useful and a > high level description of what it does. The details are in the patch > ifself and do not have to be epxlained in the changelog. > > For the technical explanation which you need to add, you really need to > tell what's the advantage or additional coverage vs. existing debug > facilities like debugobjects. Just claiming that it's useful does not > make an argument. > > The UAF problem with timers is nasty because if you free an active timer > then either the softirq which expires the timer will corrupt potentially > reused memory or the reuse will corrupt the linked list which makes the > softirq or some unrelated code which adds/removes a different timer > explode in undebuggable ways. debugobject prevents that because it > tracks per timer state and invokes the fixup function which keeps the > system alive and also tells you exactly where the free of the active > object happens which is the really interesting place to look at. The > init function is pretty uninteresting in that case because you really > want to know where the freeing of the active object happens. > It is what we want to achieve, maybe we have shortcomings, but my patch > So if KASAN detects UAF in the timer softirq then the init trace is not > giving any information especially not in cases where the timer is part > of a common and frequently allocated/freed other data structure. > > > static inline void kasan_cache_shrink(struct kmem_cache *cache) {} > > static inline void kasan_cache_shutdown(struct kmem_cache *cache) {} > > static inline void kasan_record_aux_stack(void *ptr) {} > > +static inline void kasan_record_tmr_stack(void *ptr) {} > > Duh, so you are adding per object type functions and storage? That's > going to be a huge copy and pasta orgy as every object requires the same > code and extra storage space. > > Why not just using kasan_record_aux_stack() for all of this? > > The 'call_rcu' 'timer' 'whatever next' printout is not really required > because the stack trace already tells you the function which was > invoked. If TOS is call_rcu() or do_timer_init() then it's entirely > clear which object is affected. If the two aux records are not enough > then making the array larger is not the end of the world. > > > #endif /* CONFIG_KASAN_GENERIC */ > > > > diff --git a/kernel/time/timer.c b/kernel/time/timer.c > > index a5221abb4594..ef2da9ddfac7 100644 > > --- a/kernel/time/timer.c > > +++ b/kernel/time/timer.c > > @@ -783,6 +783,8 @@ static void do_init_timer(struct timer_list *timer, > > timer->function = func; > > timer->flags = flags | raw_smp_processor_id(); > > lockdep_init_map(&timer->lockdep_map, name, key, 0); > > + > > + kasan_record_tmr_stack(timer); > > } > > Are you sure this is correct for all timers? > > This is also called for timers which are temporarily allocated on stack > and for timers which are statically allocated at compile time. How is > that supposed to work? > > These kind of things want to be explained upfront an not left to the > reviewer as an exercise. > > Thanks, > > tglx I have already _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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=-8.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=unavailable 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 3AF63C433E1 for ; Thu, 13 Aug 2020 12:28:07 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 094B8207DA for ; Thu, 13 Aug 2020 12:28:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="QHRM70IO"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="GmWMcG+B" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 094B8207DA 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+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=merlin.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=09Q6x2LCgaCAm93umehFoyFyXs2Md5szPpt1RAeBJ2Q=; b=QHRM70IOjMRnqLdBY65wRJA5o S4YZesS8slVBp9PTrsfCdLULRC8OjVaCsfL1gm39pbQnfivSHABE2eLI9VMOgmKOciaPZtJLzmqJ1 TvN7b0QIeveGRcO0GHXPacSOl2Vb9YeH/iu0ue4ImyeAnM2GjWHjryv+JcPcBwi0X+GpOcdLGLYaW f75pUZigFcHu0ZXVG81r+3B11yToJNIHjs4SGWkedbCHH3CoajlNIRcuNhSeAXdL1GNY9r/+NwxgY 4MqKe/WGB5hDmb+UjViWmaZsok5SyhfXUFEOEC9sR+xpZOTd4BGqaBCt+xxWm2/hHXrMfSoyuwZVD Q0qumyYqw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k6CJC-00013m-QK; Thu, 13 Aug 2020 12:26:14 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k6CJ9-00012u-4f; Thu, 13 Aug 2020 12:26:12 +0000 X-UUID: 4056165f5dd74230a73c1333f3521aa4-20200813 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=e41c5oYHqFyVyE7RzGdj+2oNjx9zrZ3d7b52Xcy+lRI=; b=GmWMcG+BIBGO22uTdBbkrn4zxhcIScGQV8kNkFh3aoyvpEBcuhLidVJYbbOhI7ChlNj7U0MR6x8qdXG3THfdCkFhm7VpvhPJEMlezo1v5OQOoERcGV2c9B+IZGSLTcjzEh7wEH6hX8AF+hKfpd2LTpG5oADKtYgSGq3d9Cca9V0=; X-UUID: 4056165f5dd74230a73c1333f3521aa4-20200813 Received: from mtkcas67.mediatek.inc [(172.29.193.45)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 1124127630; Thu, 13 Aug 2020 04:26:06 -0800 Received: from MTKMBS01N2.mediatek.inc (172.21.101.79) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 05:26:02 -0700 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs01n2.mediatek.inc (172.21.101.79) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 20:25:54 +0800 Received: from [172.21.84.99] (172.21.84.99) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 13 Aug 2020 20:25:54 +0800 Message-ID: <1597321556.9999.27.camel@mtksdccf07> Subject: Re: [PATCH 1/5] timer: kasan: record and print timer stack From: Walter Wu To: Thomas Gleixner Date: Thu, 13 Aug 2020 20:25:56 +0800 In-Reply-To: <87d03ulqbp.fsf@nanos.tec.linutronix.de> References: <20200810072313.529-1-walter-zh.wu@mediatek.com> <87d03ulqbp.fsf@nanos.tec.linutronix.de> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-TM-SNTS-SMTP: 6EB2F04DEDD30544E1EE481F458926A2139F49991264C64715B53AF6C629549C2000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200813_082611_310021_831DFDFF X-CRM114-Status: GOOD ( 37.90 ) 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: John Stultz , wsd_upstream , Stephen Boyd , linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, 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+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 2020-08-13 at 13:48 +0200, Thomas Gleixner wrote: > Walter, > > Walter Wu writes: > > This patch records the last two timer queueing stacks and prints > > "This patch" is useless information as we already know from the subject > line that this is a patch. > > git grep 'This patch' Documentation/process/ > Thanks for your information. > > up to 2 timer stacks in KASAN report. It is useful for programmers > > to solve use-after-free or double-free memory timer issues. > > > > When timer_setup() or timer_setup_on_stack() is called, then it > > prepares to use this timer and sets timer callback, we store > > this call stack in order to print it in KASAN report. > > we store nothing. Don't impersonate code please. > > Also please structure the changelog in a way that it's easy to > understand what this is about instead of telling first what the patch > does and then some half baken information why this is useful followed by > more information about what it does. > > Something like this: > > For analysing use after free or double free of objects it is helpful > to preserve usage history which potentially gives a hint about the > affected code. > > For timers it has turned out to be useful to record the stack trace > of the timer init call. > > Record the most recent two timer init calls in KASAN which are printed > on failure in the KASAN report. > > See, this gives a clear context, an explanation why it is useful and a > high level description of what it does. The details are in the patch > ifself and do not have to be epxlained in the changelog. > > For the technical explanation which you need to add, you really need to > tell what's the advantage or additional coverage vs. existing debug > facilities like debugobjects. Just claiming that it's useful does not > make an argument. > > The UAF problem with timers is nasty because if you free an active timer > then either the softirq which expires the timer will corrupt potentially > reused memory or the reuse will corrupt the linked list which makes the > softirq or some unrelated code which adds/removes a different timer > explode in undebuggable ways. debugobject prevents that because it > tracks per timer state and invokes the fixup function which keeps the > system alive and also tells you exactly where the free of the active > object happens which is the really interesting place to look at. The > init function is pretty uninteresting in that case because you really > want to know where the freeing of the active object happens. > It is what we want to achieve, maybe we have shortcomings, but my patch > So if KASAN detects UAF in the timer softirq then the init trace is not > giving any information especially not in cases where the timer is part > of a common and frequently allocated/freed other data structure. > > > static inline void kasan_cache_shrink(struct kmem_cache *cache) {} > > static inline void kasan_cache_shutdown(struct kmem_cache *cache) {} > > static inline void kasan_record_aux_stack(void *ptr) {} > > +static inline void kasan_record_tmr_stack(void *ptr) {} > > Duh, so you are adding per object type functions and storage? That's > going to be a huge copy and pasta orgy as every object requires the same > code and extra storage space. > > Why not just using kasan_record_aux_stack() for all of this? > > The 'call_rcu' 'timer' 'whatever next' printout is not really required > because the stack trace already tells you the function which was > invoked. If TOS is call_rcu() or do_timer_init() then it's entirely > clear which object is affected. If the two aux records are not enough > then making the array larger is not the end of the world. > > > #endif /* CONFIG_KASAN_GENERIC */ > > > > diff --git a/kernel/time/timer.c b/kernel/time/timer.c > > index a5221abb4594..ef2da9ddfac7 100644 > > --- a/kernel/time/timer.c > > +++ b/kernel/time/timer.c > > @@ -783,6 +783,8 @@ static void do_init_timer(struct timer_list *timer, > > timer->function = func; > > timer->flags = flags | raw_smp_processor_id(); > > lockdep_init_map(&timer->lockdep_map, name, key, 0); > > + > > + kasan_record_tmr_stack(timer); > > } > > Are you sure this is correct for all timers? > > This is also called for timers which are temporarily allocated on stack > and for timers which are statically allocated at compile time. How is > that supposed to work? > > These kind of things want to be explained upfront an not left to the > reviewer as an exercise. > > Thanks, > > tglx I have already _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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=-8.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=ham 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 CB552C433DF for ; Thu, 13 Aug 2020 12:26:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 67E2C2078D for ; Thu, 13 Aug 2020 12:26:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="GmWMcG+B" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 67E2C2078D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 93EB56B0007; Thu, 13 Aug 2020 08:26:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8C7F76B0008; Thu, 13 Aug 2020 08:26:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 78E666B000A; Thu, 13 Aug 2020 08:26:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0224.hostedemail.com [216.40.44.224]) by kanga.kvack.org (Postfix) with ESMTP id 5EC2C6B0007 for ; Thu, 13 Aug 2020 08:26:04 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 15B68181AEF07 for ; Thu, 13 Aug 2020 12:26:04 +0000 (UTC) X-FDA: 77145467448.21.jelly24_2b0a09626ff4 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id DA2F4180442C2 for ; Thu, 13 Aug 2020 12:26:03 +0000 (UTC) X-HE-Tag: jelly24_2b0a09626ff4 X-Filterd-Recvd-Size: 9029 Received: from mailgw01.mediatek.com (unknown [210.61.82.183]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Thu, 13 Aug 2020 12:26:02 +0000 (UTC) X-UUID: 9372ecbb5ab74080b5bf5f10feeba9a3-20200813 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=e41c5oYHqFyVyE7RzGdj+2oNjx9zrZ3d7b52Xcy+lRI=; b=GmWMcG+BIBGO22uTdBbkrn4zxhcIScGQV8kNkFh3aoyvpEBcuhLidVJYbbOhI7ChlNj7U0MR6x8qdXG3THfdCkFhm7VpvhPJEMlezo1v5OQOoERcGV2c9B+IZGSLTcjzEh7wEH6hX8AF+hKfpd2LTpG5oADKtYgSGq3d9Cca9V0=; X-UUID: 9372ecbb5ab74080b5bf5f10feeba9a3-20200813 Received: from mtkcas06.mediatek.inc [(172.21.101.30)] by mailgw01.mediatek.com (envelope-from ) (Cellopoint E-mail Firewall v4.1.10 Build 0809 with TLS) with ESMTP id 316300702; Thu, 13 Aug 2020 20:25:58 +0800 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs01n2.mediatek.inc (172.21.101.79) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 20:25:54 +0800 Received: from [172.21.84.99] (172.21.84.99) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 13 Aug 2020 20:25:54 +0800 Message-ID: <1597321556.9999.27.camel@mtksdccf07> Subject: Re: [PATCH 1/5] timer: kasan: record and print timer stack From: Walter Wu To: Thomas Gleixner CC: Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Matthias Brugger , John Stultz , "Stephen Boyd" , Andrew Morton , , , , , wsd_upstream , Date: Thu, 13 Aug 2020 20:25:56 +0800 In-Reply-To: <87d03ulqbp.fsf@nanos.tec.linutronix.de> References: <20200810072313.529-1-walter-zh.wu@mediatek.com> <87d03ulqbp.fsf@nanos.tec.linutronix.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-TM-SNTS-SMTP: 6EB2F04DEDD30544E1EE481F458926A2139F49991264C64715B53AF6C629549C2000:8 X-MTK: N Content-Transfer-Encoding: base64 X-Rspamd-Queue-Id: DA2F4180442C2 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: T24gVGh1LCAyMDIwLTA4LTEzIGF0IDEzOjQ4ICswMjAwLCBUaG9tYXMgR2xlaXhuZXIgd3JvdGU6 DQo+IFdhbHRlciwNCj4gDQo+IFdhbHRlciBXdSA8d2FsdGVyLXpoLnd1QG1lZGlhdGVrLmNvbT4g d3JpdGVzOg0KPiA+IFRoaXMgcGF0Y2ggcmVjb3JkcyB0aGUgbGFzdCB0d28gdGltZXIgcXVldWVp bmcgc3RhY2tzIGFuZCBwcmludHMNCj4gDQo+ICJUaGlzIHBhdGNoIiBpcyB1c2VsZXNzIGluZm9y bWF0aW9uIGFzIHdlIGFscmVhZHkga25vdyBmcm9tIHRoZSBzdWJqZWN0DQo+IGxpbmUgdGhhdCB0 aGlzIGlzIGEgcGF0Y2guDQo+IA0KPiBnaXQgZ3JlcCAnVGhpcyBwYXRjaCcgRG9jdW1lbnRhdGlv bi9wcm9jZXNzLw0KPiANCg0KVGhhbmtzIGZvciB5b3VyIGluZm9ybWF0aW9uLg0KDQo+ID4gdXAg dG8gMiB0aW1lciBzdGFja3MgaW4gS0FTQU4gcmVwb3J0LiBJdCBpcyB1c2VmdWwgZm9yIHByb2dy YW1tZXJzDQo+ID4gdG8gc29sdmUgdXNlLWFmdGVyLWZyZWUgb3IgZG91YmxlLWZyZWUgbWVtb3J5 IHRpbWVyIGlzc3Vlcy4NCj4gPg0KPiA+IFdoZW4gdGltZXJfc2V0dXAoKSBvciB0aW1lcl9zZXR1 cF9vbl9zdGFjaygpIGlzIGNhbGxlZCwgdGhlbiBpdA0KPiA+IHByZXBhcmVzIHRvIHVzZSB0aGlz IHRpbWVyIGFuZCBzZXRzIHRpbWVyIGNhbGxiYWNrLCB3ZSBzdG9yZQ0KPiA+IHRoaXMgY2FsbCBz dGFjayBpbiBvcmRlciB0byBwcmludCBpdCBpbiBLQVNBTiByZXBvcnQuDQo+IA0KPiB3ZSBzdG9y ZSBub3RoaW5nLiBEb24ndCBpbXBlcnNvbmF0ZSBjb2RlIHBsZWFzZS4NCj4gDQo+IEFsc28gcGxl YXNlIHN0cnVjdHVyZSB0aGUgY2hhbmdlbG9nIGluIGEgd2F5IHRoYXQgaXQncyBlYXN5IHRvDQo+ IHVuZGVyc3RhbmQgd2hhdCB0aGlzIGlzIGFib3V0IGluc3RlYWQgb2YgdGVsbGluZyBmaXJzdCB3 aGF0IHRoZSBwYXRjaA0KPiBkb2VzIGFuZCB0aGVuIHNvbWUgaGFsZiBiYWtlbiBpbmZvcm1hdGlv biB3aHkgdGhpcyBpcyB1c2VmdWwgZm9sbG93ZWQgYnkNCj4gbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCB3aGF0IGl0IGRvZXMuDQo+IA0KPiBTb21ldGhpbmcgbGlrZSB0aGlzOg0KPiANCj4gICBGb3Ig YW5hbHlzaW5nIHVzZSBhZnRlciBmcmVlIG9yIGRvdWJsZSBmcmVlIG9mIG9iamVjdHMgaXQgaXMg aGVscGZ1bA0KPiAgIHRvIHByZXNlcnZlIHVzYWdlIGhpc3Rvcnkgd2hpY2ggcG90ZW50aWFsbHkg Z2l2ZXMgYSBoaW50IGFib3V0IHRoZQ0KPiAgIGFmZmVjdGVkIGNvZGUuDQo+IA0KPiAgIEZvciB0 aW1lcnMgaXQgaGFzIHR1cm5lZCBvdXQgdG8gYmUgdXNlZnVsIHRvIHJlY29yZCB0aGUgc3RhY2sg dHJhY2UNCj4gICBvZiB0aGUgdGltZXIgaW5pdCBjYWxsLiA8QUREIHRlY2huaWNhbCBleHBsYW5h dGlvbiB3aHkgdGhpcyBpcyB1c2VmdWw+DQo+ICANCj4gICBSZWNvcmQgdGhlIG1vc3QgcmVjZW50 IHR3byB0aW1lciBpbml0IGNhbGxzIGluIEtBU0FOIHdoaWNoIGFyZSBwcmludGVkDQo+ICAgb24g ZmFpbHVyZSBpbiB0aGUgS0FTQU4gcmVwb3J0Lg0KPiANCj4gU2VlLCB0aGlzIGdpdmVzIGEgY2xl YXIgY29udGV4dCwgYW4gZXhwbGFuYXRpb24gd2h5IGl0IGlzIHVzZWZ1bCBhbmQgYQ0KPiBoaWdo IGxldmVsIGRlc2NyaXB0aW9uIG9mIHdoYXQgaXQgZG9lcy4gVGhlIGRldGFpbHMgYXJlIGluIHRo ZSBwYXRjaA0KPiBpZnNlbGYgYW5kIGRvIG5vdCBoYXZlIHRvIGJlIGVweGxhaW5lZCBpbiB0aGUg Y2hhbmdlbG9nLg0KPiANCg0KPiBGb3IgdGhlIHRlY2huaWNhbCBleHBsYW5hdGlvbiB3aGljaCB5 b3UgbmVlZCB0byBhZGQsIHlvdSByZWFsbHkgbmVlZCB0bw0KPiB0ZWxsIHdoYXQncyB0aGUgYWR2 YW50YWdlIG9yIGFkZGl0aW9uYWwgY292ZXJhZ2UgdnMuIGV4aXN0aW5nIGRlYnVnDQo+IGZhY2ls aXRpZXMgbGlrZSBkZWJ1Z29iamVjdHMuIEp1c3QgY2xhaW1pbmcgdGhhdCBpdCdzIHVzZWZ1bCBk b2VzIG5vdA0KPiBtYWtlIGFuIGFyZ3VtZW50Lg0KPiANCg0KDQoNCj4gVGhlIFVBRiBwcm9ibGVt IHdpdGggdGltZXJzIGlzIG5hc3R5IGJlY2F1c2UgaWYgeW91IGZyZWUgYW4gYWN0aXZlIHRpbWVy DQo+IHRoZW4gZWl0aGVyIHRoZSBzb2Z0aXJxIHdoaWNoIGV4cGlyZXMgdGhlIHRpbWVyIHdpbGwg Y29ycnVwdCBwb3RlbnRpYWxseQ0KPiByZXVzZWQgbWVtb3J5IG9yIHRoZSByZXVzZSB3aWxsIGNv cnJ1cHQgdGhlIGxpbmtlZCBsaXN0IHdoaWNoIG1ha2VzIHRoZQ0KPiBzb2Z0aXJxIG9yIHNvbWUg dW5yZWxhdGVkIGNvZGUgd2hpY2ggYWRkcy9yZW1vdmVzIGEgZGlmZmVyZW50IHRpbWVyDQo+IGV4 cGxvZGUgaW4gdW5kZWJ1Z2dhYmxlIHdheXMuIGRlYnVnb2JqZWN0IHByZXZlbnRzIHRoYXQgYmVj YXVzZSBpdA0KPiB0cmFja3MgcGVyIHRpbWVyIHN0YXRlIGFuZCBpbnZva2VzIHRoZSBmaXh1cCBm dW5jdGlvbiB3aGljaCBrZWVwcyB0aGUNCj4gc3lzdGVtIGFsaXZlIGFuZCBhbHNvIHRlbGxzIHlv dSBleGFjdGx5IHdoZXJlIHRoZSBmcmVlIG9mIHRoZSBhY3RpdmUNCj4gb2JqZWN0IGhhcHBlbnMg d2hpY2ggaXMgdGhlIHJlYWxseSBpbnRlcmVzdGluZyBwbGFjZSB0byBsb29rIGF0LiBUaGUNCj4g aW5pdCBmdW5jdGlvbiBpcyBwcmV0dHkgdW5pbnRlcmVzdGluZyBpbiB0aGF0IGNhc2UgYmVjYXVz ZSB5b3UgcmVhbGx5DQo+IHdhbnQgdG8ga25vdyB3aGVyZSB0aGUgZnJlZWluZyBvZiB0aGUgYWN0 aXZlIG9iamVjdCBoYXBwZW5zLg0KPiANCg0KSXQgaXMgd2hhdCB3ZSB3YW50IHRvIGFjaGlldmUs IG1heWJlIHdlIGhhdmUgc2hvcnRjb21pbmdzLCBidXQgbXkgcGF0Y2gNCg0KPiBTbyBpZiBLQVNB TiBkZXRlY3RzIFVBRiBpbiB0aGUgdGltZXIgc29mdGlycSB0aGVuIHRoZSBpbml0IHRyYWNlIGlz IG5vdA0KPiBnaXZpbmcgYW55IGluZm9ybWF0aW9uIGVzcGVjaWFsbHkgbm90IGluIGNhc2VzIHdo ZXJlIHRoZSB0aW1lciBpcyBwYXJ0DQo+IG9mIGEgY29tbW9uIGFuZCBmcmVxdWVudGx5IGFsbG9j YXRlZC9mcmVlZCBvdGhlciBkYXRhIHN0cnVjdHVyZS4NCj4gDQo+ID4gIHN0YXRpYyBpbmxpbmUg dm9pZCBrYXNhbl9jYWNoZV9zaHJpbmsoc3RydWN0IGttZW1fY2FjaGUgKmNhY2hlKSB7fQ0KPiA+ ICBzdGF0aWMgaW5saW5lIHZvaWQga2FzYW5fY2FjaGVfc2h1dGRvd24oc3RydWN0IGttZW1fY2Fj aGUgKmNhY2hlKSB7fQ0KPiA+ICBzdGF0aWMgaW5saW5lIHZvaWQga2FzYW5fcmVjb3JkX2F1eF9z dGFjayh2b2lkICpwdHIpIHt9DQo+ID4gK3N0YXRpYyBpbmxpbmUgdm9pZCBrYXNhbl9yZWNvcmRf dG1yX3N0YWNrKHZvaWQgKnB0cikge30NCj4gDQo+IER1aCwgc28geW91IGFyZSBhZGRpbmcgcGVy IG9iamVjdCB0eXBlIGZ1bmN0aW9ucyBhbmQgc3RvcmFnZT8gVGhhdCdzDQo+IGdvaW5nIHRvIGJl IGEgaHVnZSBjb3B5IGFuZCBwYXN0YSBvcmd5IGFzIGV2ZXJ5IG9iamVjdCByZXF1aXJlcyB0aGUg c2FtZQ0KPiBjb2RlIGFuZCBleHRyYSBzdG9yYWdlIHNwYWNlLg0KPiANCj4gV2h5IG5vdCBqdXN0 IHVzaW5nIGthc2FuX3JlY29yZF9hdXhfc3RhY2soKSBmb3IgYWxsIG9mIHRoaXM/DQo+IA0KPiBU aGUgJ2NhbGxfcmN1JyAndGltZXInICd3aGF0ZXZlciBuZXh0JyBwcmludG91dCBpcyBub3QgcmVh bGx5IHJlcXVpcmVkDQo+IGJlY2F1c2UgdGhlIHN0YWNrIHRyYWNlIGFscmVhZHkgdGVsbHMgeW91 IHRoZSBmdW5jdGlvbiB3aGljaCB3YXMNCj4gaW52b2tlZC4gSWYgVE9TIGlzIGNhbGxfcmN1KCkg b3IgZG9fdGltZXJfaW5pdCgpIHRoZW4gaXQncyBlbnRpcmVseQ0KPiBjbGVhciB3aGljaCBvYmpl Y3QgaXMgYWZmZWN0ZWQuIElmIHRoZSB0d28gYXV4IHJlY29yZHMgYXJlIG5vdCBlbm91Z2gNCj4g dGhlbiBtYWtpbmcgdGhlIGFycmF5IGxhcmdlciBpcyBub3QgdGhlIGVuZCBvZiB0aGUgd29ybGQu DQo+IA0KPiA+ICAjZW5kaWYgLyogQ09ORklHX0tBU0FOX0dFTkVSSUMgKi8NCj4gPiAgDQo+ID4g ZGlmZiAtLWdpdCBhL2tlcm5lbC90aW1lL3RpbWVyLmMgYi9rZXJuZWwvdGltZS90aW1lci5jDQo+ ID4gaW5kZXggYTUyMjFhYmI0NTk0Li5lZjJkYTlkZGZhYzcgMTAwNjQ0DQo+ID4gLS0tIGEva2Vy bmVsL3RpbWUvdGltZXIuYw0KPiA+ICsrKyBiL2tlcm5lbC90aW1lL3RpbWVyLmMNCj4gPiBAQCAt NzgzLDYgKzc4Myw4IEBAIHN0YXRpYyB2b2lkIGRvX2luaXRfdGltZXIoc3RydWN0IHRpbWVyX2xp c3QgKnRpbWVyLA0KPiA+ICAJdGltZXItPmZ1bmN0aW9uID0gZnVuYzsNCj4gPiAgCXRpbWVyLT5m bGFncyA9IGZsYWdzIHwgcmF3X3NtcF9wcm9jZXNzb3JfaWQoKTsNCj4gPiAgCWxvY2tkZXBfaW5p dF9tYXAoJnRpbWVyLT5sb2NrZGVwX21hcCwgbmFtZSwga2V5LCAwKTsNCj4gPiArDQo+ID4gKwlr YXNhbl9yZWNvcmRfdG1yX3N0YWNrKHRpbWVyKTsNCj4gPiAgfQ0KPiANCj4gQXJlIHlvdSBzdXJl IHRoaXMgaXMgY29ycmVjdCBmb3IgYWxsIHRpbWVycz8NCj4gDQo+IFRoaXMgaXMgYWxzbyBjYWxs ZWQgZm9yIHRpbWVycyB3aGljaCBhcmUgdGVtcG9yYXJpbHkgYWxsb2NhdGVkIG9uIHN0YWNrDQo+ IGFuZCBmb3IgdGltZXJzIHdoaWNoIGFyZSBzdGF0aWNhbGx5IGFsbG9jYXRlZCBhdCBjb21waWxl IHRpbWUuIEhvdyBpcw0KPiB0aGF0IHN1cHBvc2VkIHRvIHdvcms/DQo+IA0KPiBUaGVzZSBraW5k IG9mIHRoaW5ncyB3YW50IHRvIGJlIGV4cGxhaW5lZCB1cGZyb250IGFuIG5vdCBsZWZ0IHRvIHRo ZQ0KPiByZXZpZXdlciBhcyBhbiBleGVyY2lzZS4NCj4gDQo+IFRoYW5rcywNCj4gDQo+ICAgICAg ICAgdGdseA0KDQpJIGhhdmUgYWxyZWFkeSANCg0K