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 3676AC433DF for ; Thu, 13 Aug 2020 12:51:17 +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 AF24A20791 for ; Thu, 13 Aug 2020 12:51:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="He6Wkwg9"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="BOIL1Rth" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AF24A20791 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=HGn1DoICqXw4nvGu4Uvj2hBRGeNUNpU+hJfwofugAEg=; b=He6Wkwg9mU4c9I913mmnylkLA Z+JCeA6QGtemPJ2bY5aXMp7baGFUPMLaLIQdOPLLNZA+8KqvZNmfaSy2435jHfpqulZZfGrmJtyDS vf76d/1VS4SODby1vcDhB7gI4vRothc2WTKmyyet8+F5x+6qvDnTE5xOTDpby44W3kRkUKGprdURB H+fiXBIdi+419Nmk8mPYtdvimvL+MWcIfh77tL3wRMFz8Ty6oFaAaNRQJFtiyeRJSUX1dvva+8Btv ZG5vRM+TW+m6wU+KP+fsGvfZj7HMt0HdGA544LE3O57tpZSan4p8Yu0iRhiydSOyu3WXAflG/YebY 2fIkkx41g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k6ChA-0005Qg-Dg; Thu, 13 Aug 2020 12:51:00 +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 1k6CfJ-0004TP-4C; Thu, 13 Aug 2020 12:49:09 +0000 X-UUID: bd8aaff32b07494b8f9b751b447b8803-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=aaE6HcSMNBLCW8HhXQtINfxBXNzqkMSqUtGQrGAVPSM=; b=BOIL1Rthkq9dh/cIjPy+2394BryYEPZfVPl/p+WsDexLcm3qgQzNuBPsL0vAbg37mWo9/dLo2BbPnRGsW8DFgSdQLfM7yeckhVTy/TqVPueTsFo02M+ubzkfdnErZR0RGBMNia4m2X8yPfKS1hN2oImOc4oPWc9W6sKsqNaEzNA=; X-UUID: bd8aaff32b07494b8f9b751b447b8803-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 1844085126; Thu, 13 Aug 2020 04:49:00 -0800 Received: from MTKMBS01N1.mediatek.inc (172.21.101.68) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 05:48:57 -0700 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs01n1.mediatek.inc (172.21.101.68) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 20:48:55 +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.1497.2 via Frontend Transport; Thu, 13 Aug 2020 20:48:57 +0800 Message-ID: <1597322937.9999.42.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:48:57 +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-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200813_084905_463179_9E5C9661 X-CRM114-Status: GOOD ( 40.61 ) 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 Hi Thomas, Please ignore my previous mail. Thanks. 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. > Thanks for your explanation, Our patch will use this as a template from now on. > 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. > We originally wanted him to have similar functions. Maybe he can't completely replace, but KASAN can ave this ability. > 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. > > 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. > I don't have experience using this tool, but I will survey it. > > 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. > My previous mail say that we will re-use kasan_record_aux_stack() and only have aux_stack. > > #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? > If I understand correctly, KASAN report have this record only for slub variable. So what you said shouldn't be a problem. > These kind of things want to be explained upfront an not left to the > reviewer as an exercise. > Sorry, My fault. Later we will be more cautious to send patch. > Thanks, > > tglx _______________________________________________ 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 BB201C433DF for ; Thu, 13 Aug 2020 12:52:32 +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 8B04920791 for ; Thu, 13 Aug 2020 12:52:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="EJLfgJU7"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="BOIL1Rth" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8B04920791 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=kcocx+T3BCcynkujv56kj77wY5+0jBD9MZtH8RCw79U=; b=EJLfgJU7Of+GiQeer+DL5+4GK j1CC18IJitNIXd9XEiSlVZzC1tyejXM6BqXQKFObq65C1GGaM6bAVRPjNvEIr6Ihsk6+dV5edYSM0 S4WTlpcT64RY3l3L++3aEmxe9PwcxtaAVDVS3SZJQvVQq3tnEDPVYiytg3MBsq9mZqPFNLorfI6wk 4xbyRccdS5ZCtTLnx/pu37bsMm6wYKveX2DiQhHYEq8HWdhI9cEhgW1BVxDbeg701gQroMjJBZz2N QQbSlb1lZsYNpQrXlVkLAATvmkWScyLlWAUWadWqb6fIZSwDgo4MHFAOv4Irrvancrr5rcr+2JEnx m7sdGlCKw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k6CgZ-00053J-Q8; Thu, 13 Aug 2020 12:50:25 +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 1k6CfJ-0004TP-4C; Thu, 13 Aug 2020 12:49:09 +0000 X-UUID: bd8aaff32b07494b8f9b751b447b8803-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=aaE6HcSMNBLCW8HhXQtINfxBXNzqkMSqUtGQrGAVPSM=; b=BOIL1Rthkq9dh/cIjPy+2394BryYEPZfVPl/p+WsDexLcm3qgQzNuBPsL0vAbg37mWo9/dLo2BbPnRGsW8DFgSdQLfM7yeckhVTy/TqVPueTsFo02M+ubzkfdnErZR0RGBMNia4m2X8yPfKS1hN2oImOc4oPWc9W6sKsqNaEzNA=; X-UUID: bd8aaff32b07494b8f9b751b447b8803-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 1844085126; Thu, 13 Aug 2020 04:49:00 -0800 Received: from MTKMBS01N1.mediatek.inc (172.21.101.68) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 05:48:57 -0700 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs01n1.mediatek.inc (172.21.101.68) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 20:48:55 +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.1497.2 via Frontend Transport; Thu, 13 Aug 2020 20:48:57 +0800 Message-ID: <1597322937.9999.42.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:48:57 +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-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200813_084905_463179_9E5C9661 X-CRM114-Status: GOOD ( 40.61 ) 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 Hi Thomas, Please ignore my previous mail. Thanks. 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. > Thanks for your explanation, Our patch will use this as a template from now on. > 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. > We originally wanted him to have similar functions. Maybe he can't completely replace, but KASAN can ave this ability. > 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. > > 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. > I don't have experience using this tool, but I will survey it. > > 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. > My previous mail say that we will re-use kasan_record_aux_stack() and only have aux_stack. > > #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? > If I understand correctly, KASAN report have this record only for slub variable. So what you said shouldn't be a problem. > These kind of things want to be explained upfront an not left to the > reviewer as an exercise. > Sorry, My fault. Later we will be more cautious to send patch. > Thanks, > > tglx _______________________________________________ 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 C16D2C433E3 for ; Thu, 13 Aug 2020 12:49:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8679A20791 for ; Thu, 13 Aug 2020 12:49:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="BOIL1Rth" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8679A20791 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 0853A8D0001; Thu, 13 Aug 2020 08:49:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 035886B0007; Thu, 13 Aug 2020 08:49:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E693A8D0001; Thu, 13 Aug 2020 08:49:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0165.hostedemail.com [216.40.44.165]) by kanga.kvack.org (Postfix) with ESMTP id CE18E6B0005 for ; Thu, 13 Aug 2020 08:49:04 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 97A6A2481 for ; Thu, 13 Aug 2020 12:49:04 +0000 (UTC) X-FDA: 77145525408.14.cats31_370fd3326ff4 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id 6588018229835 for ; Thu, 13 Aug 2020 12:49:04 +0000 (UTC) X-HE-Tag: cats31_370fd3326ff4 X-Filterd-Recvd-Size: 9660 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Thu, 13 Aug 2020 12:49:02 +0000 (UTC) X-UUID: f4c7400723df461b99ba43db2a1c039f-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=aaE6HcSMNBLCW8HhXQtINfxBXNzqkMSqUtGQrGAVPSM=; b=BOIL1Rthkq9dh/cIjPy+2394BryYEPZfVPl/p+WsDexLcm3qgQzNuBPsL0vAbg37mWo9/dLo2BbPnRGsW8DFgSdQLfM7yeckhVTy/TqVPueTsFo02M+ubzkfdnErZR0RGBMNia4m2X8yPfKS1hN2oImOc4oPWc9W6sKsqNaEzNA=; X-UUID: f4c7400723df461b99ba43db2a1c039f-20200813 Received: from mtkcas10.mediatek.inc [(172.21.101.39)] by mailgw02.mediatek.com (envelope-from ) (Cellopoint E-mail Firewall v4.1.10 Build 0809 with TLS) with ESMTP id 388844126; Thu, 13 Aug 2020 20:48:58 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs01n1.mediatek.inc (172.21.101.68) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 20:48:55 +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.1497.2 via Frontend Transport; Thu, 13 Aug 2020 20:48:57 +0800 Message-ID: <1597322937.9999.42.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:48:57 +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-MTK: N Content-Transfer-Encoding: base64 X-Rspamd-Queue-Id: 6588018229835 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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: SGkgVGhvbWFzLA0KDQpQbGVhc2UgaWdub3JlIG15IHByZXZpb3VzIG1haWwuIFRoYW5rcy4NCg0K DQpPbiBUaHUsIDIwMjAtMDgtMTMgYXQgMTM6NDggKzAyMDAsIFRob21hcyBHbGVpeG5lciB3cm90 ZToNCj4gV2FsdGVyLA0KPiANCj4gV2FsdGVyIFd1IDx3YWx0ZXItemgud3VAbWVkaWF0ZWsuY29t PiB3cml0ZXM6DQo+ID4gVGhpcyBwYXRjaCByZWNvcmRzIHRoZSBsYXN0IHR3byB0aW1lciBxdWV1 ZWluZyBzdGFja3MgYW5kIHByaW50cw0KPiANCj4gIlRoaXMgcGF0Y2giIGlzIHVzZWxlc3MgaW5m b3JtYXRpb24gYXMgd2UgYWxyZWFkeSBrbm93IGZyb20gdGhlIHN1YmplY3QNCj4gbGluZSB0aGF0 IHRoaXMgaXMgYSBwYXRjaC4NCj4gDQo+IGdpdCBncmVwICdUaGlzIHBhdGNoJyBEb2N1bWVudGF0 aW9uL3Byb2Nlc3MvDQo+IA0KDQpUaGFua3MgZm9yIHlvdXIgaW5mb3JtYXRpb24uDQoNCj4gPiB1 cCB0byAyIHRpbWVyIHN0YWNrcyBpbiBLQVNBTiByZXBvcnQuIEl0IGlzIHVzZWZ1bCBmb3IgcHJv Z3JhbW1lcnMNCj4gPiB0byBzb2x2ZSB1c2UtYWZ0ZXItZnJlZSBvciBkb3VibGUtZnJlZSBtZW1v cnkgdGltZXIgaXNzdWVzLg0KPiA+DQo+ID4gV2hlbiB0aW1lcl9zZXR1cCgpIG9yIHRpbWVyX3Nl dHVwX29uX3N0YWNrKCkgaXMgY2FsbGVkLCB0aGVuIGl0DQo+ID4gcHJlcGFyZXMgdG8gdXNlIHRo aXMgdGltZXIgYW5kIHNldHMgdGltZXIgY2FsbGJhY2ssIHdlIHN0b3JlDQo+ID4gdGhpcyBjYWxs IHN0YWNrIGluIG9yZGVyIHRvIHByaW50IGl0IGluIEtBU0FOIHJlcG9ydC4NCj4gDQo+IHdlIHN0 b3JlIG5vdGhpbmcuIERvbid0IGltcGVyc29uYXRlIGNvZGUgcGxlYXNlLg0KPiANCj4gQWxzbyBw bGVhc2Ugc3RydWN0dXJlIHRoZSBjaGFuZ2Vsb2cgaW4gYSB3YXkgdGhhdCBpdCdzIGVhc3kgdG8N Cj4gdW5kZXJzdGFuZCB3aGF0IHRoaXMgaXMgYWJvdXQgaW5zdGVhZCBvZiB0ZWxsaW5nIGZpcnN0 IHdoYXQgdGhlIHBhdGNoDQo+IGRvZXMgYW5kIHRoZW4gc29tZSBoYWxmIGJha2VuIGluZm9ybWF0 aW9uIHdoeSB0aGlzIGlzIHVzZWZ1bCBmb2xsb3dlZCBieQ0KPiBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHdoYXQgaXQgZG9lcy4NCj4gDQo+IFNvbWV0aGluZyBsaWtlIHRoaXM6DQo+IA0KPiAgIEZv ciBhbmFseXNpbmcgdXNlIGFmdGVyIGZyZWUgb3IgZG91YmxlIGZyZWUgb2Ygb2JqZWN0cyBpdCBp cyBoZWxwZnVsDQo+ICAgdG8gcHJlc2VydmUgdXNhZ2UgaGlzdG9yeSB3aGljaCBwb3RlbnRpYWxs eSBnaXZlcyBhIGhpbnQgYWJvdXQgdGhlDQo+ICAgYWZmZWN0ZWQgY29kZS4NCj4gDQo+ICAgRm9y IHRpbWVycyBpdCBoYXMgdHVybmVkIG91dCB0byBiZSB1c2VmdWwgdG8gcmVjb3JkIHRoZSBzdGFj ayB0cmFjZQ0KPiAgIG9mIHRoZSB0aW1lciBpbml0IGNhbGwuIDxBREQgdGVjaG5pY2FsIGV4cGxh bmF0aW9uIHdoeSB0aGlzIGlzIHVzZWZ1bD4NCj4gIA0KPiAgIFJlY29yZCB0aGUgbW9zdCByZWNl bnQgdHdvIHRpbWVyIGluaXQgY2FsbHMgaW4gS0FTQU4gd2hpY2ggYXJlIHByaW50ZWQNCj4gICBv biBmYWlsdXJlIGluIHRoZSBLQVNBTiByZXBvcnQuDQo+IA0KPiBTZWUsIHRoaXMgZ2l2ZXMgYSBj bGVhciBjb250ZXh0LCBhbiBleHBsYW5hdGlvbiB3aHkgaXQgaXMgdXNlZnVsIGFuZCBhDQo+IGhp Z2ggbGV2ZWwgZGVzY3JpcHRpb24gb2Ygd2hhdCBpdCBkb2VzLiBUaGUgZGV0YWlscyBhcmUgaW4g dGhlIHBhdGNoDQo+IGlmc2VsZiBhbmQgZG8gbm90IGhhdmUgdG8gYmUgZXB4bGFpbmVkIGluIHRo ZSBjaGFuZ2Vsb2cuDQo+IA0KDQpUaGFua3MgZm9yIHlvdXIgZXhwbGFuYXRpb24sIE91ciBwYXRj aCB3aWxsIHVzZSB0aGlzIGFzIGEgdGVtcGxhdGUgZnJvbQ0Kbm93IG9uLg0KDQo+IEZvciB0aGUg dGVjaG5pY2FsIGV4cGxhbmF0aW9uIHdoaWNoIHlvdSBuZWVkIHRvIGFkZCwgeW91IHJlYWxseSBu ZWVkIHRvDQo+IHRlbGwgd2hhdCdzIHRoZSBhZHZhbnRhZ2Ugb3IgYWRkaXRpb25hbCBjb3ZlcmFn ZSB2cy4gZXhpc3RpbmcgZGVidWcNCj4gZmFjaWxpdGllcyBsaWtlIGRlYnVnb2JqZWN0cy4gSnVz dCBjbGFpbWluZyB0aGF0IGl0J3MgdXNlZnVsIGRvZXMgbm90DQo+IG1ha2UgYW4gYXJndW1lbnQu DQo+IA0KDQpXZSBvcmlnaW5hbGx5IHdhbnRlZCBoaW0gdG8gaGF2ZSBzaW1pbGFyIGZ1bmN0aW9u cy4gTWF5YmUgaGUgY2FuJ3QNCmNvbXBsZXRlbHkgcmVwbGFjZSwgYnV0IEtBU0FOIGNhbiBhdmUg dGhpcyBhYmlsaXR5Lg0KDQo+IFRoZSBVQUYgcHJvYmxlbSB3aXRoIHRpbWVycyBpcyBuYXN0eSBi ZWNhdXNlIGlmIHlvdSBmcmVlIGFuIGFjdGl2ZSB0aW1lcg0KPiB0aGVuIGVpdGhlciB0aGUgc29m dGlycSB3aGljaCBleHBpcmVzIHRoZSB0aW1lciB3aWxsIGNvcnJ1cHQgcG90ZW50aWFsbHkNCj4g cmV1c2VkIG1lbW9yeSBvciB0aGUgcmV1c2Ugd2lsbCBjb3JydXB0IHRoZSBsaW5rZWQgbGlzdCB3 aGljaCBtYWtlcyB0aGUNCj4gc29mdGlycSBvciBzb21lIHVucmVsYXRlZCBjb2RlIHdoaWNoIGFk ZHMvcmVtb3ZlcyBhIGRpZmZlcmVudCB0aW1lcg0KPiBleHBsb2RlIGluIHVuZGVidWdnYWJsZSB3 YXlzLiBkZWJ1Z29iamVjdCBwcmV2ZW50cyB0aGF0IGJlY2F1c2UgaXQNCj4gdHJhY2tzIHBlciB0 aW1lciBzdGF0ZSBhbmQgaW52b2tlcyB0aGUgZml4dXAgZnVuY3Rpb24gd2hpY2gga2VlcHMgdGhl DQo+IHN5c3RlbSBhbGl2ZSBhbmQgYWxzbyB0ZWxscyB5b3UgZXhhY3RseSB3aGVyZSB0aGUgZnJl ZSBvZiB0aGUgYWN0aXZlDQo+IG9iamVjdCBoYXBwZW5zIHdoaWNoIGlzIHRoZSByZWFsbHkgaW50 ZXJlc3RpbmcgcGxhY2UgdG8gbG9vayBhdC4gVGhlDQo+IGluaXQgZnVuY3Rpb24gaXMgcHJldHR5 IHVuaW50ZXJlc3RpbmcgaW4gdGhhdCBjYXNlIGJlY2F1c2UgeW91IHJlYWxseQ0KPiB3YW50IHRv IGtub3cgd2hlcmUgdGhlIGZyZWVpbmcgb2YgdGhlIGFjdGl2ZSBvYmplY3QgaGFwcGVucy4NCj4g DQo+IFNvIGlmIEtBU0FOIGRldGVjdHMgVUFGIGluIHRoZSB0aW1lciBzb2Z0aXJxIHRoZW4gdGhl IGluaXQgdHJhY2UgaXMgbm90DQo+IGdpdmluZyBhbnkgaW5mb3JtYXRpb24gZXNwZWNpYWxseSBu b3QgaW4gY2FzZXMgd2hlcmUgdGhlIHRpbWVyIGlzIHBhcnQNCj4gb2YgYSBjb21tb24gYW5kIGZy ZXF1ZW50bHkgYWxsb2NhdGVkL2ZyZWVkIG90aGVyIGRhdGEgc3RydWN0dXJlLg0KPiANCg0KSSBk b24ndCBoYXZlIGV4cGVyaWVuY2UgdXNpbmcgdGhpcyB0b29sLCBidXQgSSB3aWxsIHN1cnZleSBp dC4NCg0KPiA+ICBzdGF0aWMgaW5saW5lIHZvaWQga2FzYW5fY2FjaGVfc2hyaW5rKHN0cnVjdCBr bWVtX2NhY2hlICpjYWNoZSkge30NCj4gPiAgc3RhdGljIGlubGluZSB2b2lkIGthc2FuX2NhY2hl X3NodXRkb3duKHN0cnVjdCBrbWVtX2NhY2hlICpjYWNoZSkge30NCj4gPiAgc3RhdGljIGlubGlu ZSB2b2lkIGthc2FuX3JlY29yZF9hdXhfc3RhY2sodm9pZCAqcHRyKSB7fQ0KPiA+ICtzdGF0aWMg aW5saW5lIHZvaWQga2FzYW5fcmVjb3JkX3Rtcl9zdGFjayh2b2lkICpwdHIpIHt9DQo+IA0KPiBE dWgsIHNvIHlvdSBhcmUgYWRkaW5nIHBlciBvYmplY3QgdHlwZSBmdW5jdGlvbnMgYW5kIHN0b3Jh Z2U/IFRoYXQncw0KPiBnb2luZyB0byBiZSBhIGh1Z2UgY29weSBhbmQgcGFzdGEgb3JneSBhcyBl dmVyeSBvYmplY3QgcmVxdWlyZXMgdGhlIHNhbWUNCj4gY29kZSBhbmQgZXh0cmEgc3RvcmFnZSBz cGFjZS4NCj4gDQo+IFdoeSBub3QganVzdCB1c2luZyBrYXNhbl9yZWNvcmRfYXV4X3N0YWNrKCkg Zm9yIGFsbCBvZiB0aGlzPw0KPiANCj4gVGhlICdjYWxsX3JjdScgJ3RpbWVyJyAnd2hhdGV2ZXIg bmV4dCcgcHJpbnRvdXQgaXMgbm90IHJlYWxseSByZXF1aXJlZA0KPiBiZWNhdXNlIHRoZSBzdGFj ayB0cmFjZSBhbHJlYWR5IHRlbGxzIHlvdSB0aGUgZnVuY3Rpb24gd2hpY2ggd2FzDQo+IGludm9r ZWQuIElmIFRPUyBpcyBjYWxsX3JjdSgpIG9yIGRvX3RpbWVyX2luaXQoKSB0aGVuIGl0J3MgZW50 aXJlbHkNCj4gY2xlYXIgd2hpY2ggb2JqZWN0IGlzIGFmZmVjdGVkLiBJZiB0aGUgdHdvIGF1eCBy ZWNvcmRzIGFyZSBub3QgZW5vdWdoDQo+IHRoZW4gbWFraW5nIHRoZSBhcnJheSBsYXJnZXIgaXMg bm90IHRoZSBlbmQgb2YgdGhlIHdvcmxkLg0KPiANCg0KTXkgcHJldmlvdXMgbWFpbCBzYXkgdGhh dCB3ZSB3aWxsIHJlLXVzZSBrYXNhbl9yZWNvcmRfYXV4X3N0YWNrKCkgYW5kDQpvbmx5IGhhdmUg YXV4X3N0YWNrLg0KDQo+ID4gICNlbmRpZiAvKiBDT05GSUdfS0FTQU5fR0VORVJJQyAqLw0KPiA+ ICANCj4gPiBkaWZmIC0tZ2l0IGEva2VybmVsL3RpbWUvdGltZXIuYyBiL2tlcm5lbC90aW1lL3Rp bWVyLmMNCj4gPiBpbmRleCBhNTIyMWFiYjQ1OTQuLmVmMmRhOWRkZmFjNyAxMDA2NDQNCj4gPiAt LS0gYS9rZXJuZWwvdGltZS90aW1lci5jDQo+ID4gKysrIGIva2VybmVsL3RpbWUvdGltZXIuYw0K PiA+IEBAIC03ODMsNiArNzgzLDggQEAgc3RhdGljIHZvaWQgZG9faW5pdF90aW1lcihzdHJ1Y3Qg dGltZXJfbGlzdCAqdGltZXIsDQo+ID4gIAl0aW1lci0+ZnVuY3Rpb24gPSBmdW5jOw0KPiA+ICAJ dGltZXItPmZsYWdzID0gZmxhZ3MgfCByYXdfc21wX3Byb2Nlc3Nvcl9pZCgpOw0KPiA+ICAJbG9j a2RlcF9pbml0X21hcCgmdGltZXItPmxvY2tkZXBfbWFwLCBuYW1lLCBrZXksIDApOw0KPiA+ICsN Cj4gPiArCWthc2FuX3JlY29yZF90bXJfc3RhY2sodGltZXIpOw0KPiA+ICB9DQo+IA0KPiBBcmUg eW91IHN1cmUgdGhpcyBpcyBjb3JyZWN0IGZvciBhbGwgdGltZXJzPw0KPiANCj4gVGhpcyBpcyBh bHNvIGNhbGxlZCBmb3IgdGltZXJzIHdoaWNoIGFyZSB0ZW1wb3JhcmlseSBhbGxvY2F0ZWQgb24g c3RhY2sNCj4gYW5kIGZvciB0aW1lcnMgd2hpY2ggYXJlIHN0YXRpY2FsbHkgYWxsb2NhdGVkIGF0 IGNvbXBpbGUgdGltZS4gSG93IGlzDQo+IHRoYXQgc3VwcG9zZWQgdG8gd29yaz8NCj4gDQoNCklm IEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIEtBU0FOIHJlcG9ydCBoYXZlIHRoaXMgcmVjb3JkIG9u bHkgZm9yIHNsdWINCnZhcmlhYmxlLiBTbyB3aGF0IHlvdSBzYWlkIHNob3VsZG4ndCBiZSBhIHBy b2JsZW0uDQoNCj4gVGhlc2Uga2luZCBvZiB0aGluZ3Mgd2FudCB0byBiZSBleHBsYWluZWQgdXBm cm9udCBhbiBub3QgbGVmdCB0byB0aGUNCj4gcmV2aWV3ZXIgYXMgYW4gZXhlcmNpc2UuDQo+IA0K DQpTb3JyeSwgTXkgZmF1bHQuIExhdGVyIHdlIHdpbGwgYmUgbW9yZSBjYXV0aW91cyB0byBzZW5k IHBhdGNoLg0KDQo+IFRoYW5rcywNCj4gDQo+ICAgICAgICAgdGdseA0KDQo=