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.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 E5038C2D0F8 for ; Wed, 13 May 2020 06:51:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A82A320708 for ; Wed, 13 May 2020 06:51:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="MVQ6mRj0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A82A320708 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 423E7900107; Wed, 13 May 2020 02:51:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D4299000F3; Wed, 13 May 2020 02:51:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2C23A900107; Wed, 13 May 2020 02:51:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0253.hostedemail.com [216.40.44.253]) by kanga.kvack.org (Postfix) with ESMTP id 118DE9000F3 for ; Wed, 13 May 2020 02:51:41 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id BCDB821EA for ; Wed, 13 May 2020 06:51:40 +0000 (UTC) X-FDA: 76810775160.25.step08_65ed6a5ec0707 X-HE-Tag: step08_65ed6a5ec0707 X-Filterd-Recvd-Size: 6421 Received: from mail-qv1-f67.google.com (mail-qv1-f67.google.com [209.85.219.67]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Wed, 13 May 2020 06:51:40 +0000 (UTC) Received: by mail-qv1-f67.google.com with SMTP id ee19so4211730qvb.11 for ; Tue, 12 May 2020 23:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e6QbSlNOUjKcG/ZMZ3XtXHK+IfmeCzylC8Xkh73q0Aw=; b=MVQ6mRj0yNs3gHcYY1RhK7VD4fpo64JAOOyD3f9QApNHT5ECfY+bzA0iu4QBJTzYGj sA7TY7dhSyq2eZ3vCVhqHAasszCcpxlanbJ4PJmu+fgoh6Jc0ib1eNbQCgx51n87cV1N MOer2/trIkbKluf0nZZ5UsxSJZFCjjGMX3ntmF0SGx2sfsHqQ9Xw7ZdryxDMzlPnJvxi +6Oc1Ex9QvdOZvGWuqY3FBHWZjufRAUNJNetSevZIZO+CkK4J1WPd4yTXRIohwE55qZt nKVakGPU/7m2ky+3FKJ3ne82FeecYwDpaVUs1bWJowijAAVPkaIPhV6imjhEENxutcLW Q3fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e6QbSlNOUjKcG/ZMZ3XtXHK+IfmeCzylC8Xkh73q0Aw=; b=FQBgYzq8XpefQZabipW4dvZDHACRlsV6EaXpXkSOD23RM17bTE7bSa0b64OSY+UTLx qsE4dEMU+sq8ODFi1N0T5WHxlG4xtoM/KZHIJwl7slQAYaAQY/a2ZArD/4E9yLDU6KT2 DnxifqMCOw5bq7D/VmPhCYaxZylX//kZZ/irCdE83+lLdxbmYqPTvQiMAOwcIikLUfoz 3mEzZRtzCCIjw8dYWTwKNF0xckSA+eJa3XadM5jGT5mLvz8xVJ/vJxa7/tE8vPUXU+5y uGFZOO3CvUwFQpzJ0bB9Nqh/A8IUhySYff04MUXue5NZBDlTeFpzWfXOM5H84BtBtmDQ Nkfw== X-Gm-Message-State: AOAM5308yPpFeVufYPHwle4+8RHOjJpzZJXu7qKB8txhM5MP322kagkL s/NpqfqUin/KSSH1manQXZkMY5CYbi2ceJoXDQPLrw== X-Google-Smtp-Source: ABdhPJzBnUTR6RvAjncvdb7vGMZz94R3H7YmuTqlHzue8QlAYuySzcqHBeO3N/Rhg2Akb9/rP06VmQA6b5coJoEpJ4o= X-Received: by 2002:a0c:f153:: with SMTP id y19mr909681qvl.22.1589352699379; Tue, 12 May 2020 23:51:39 -0700 (PDT) MIME-Version: 1.0 References: <20200511023111.15310-1-walter-zh.wu@mediatek.com> <1589203771.21284.22.camel@mtksdccf07> <1589254720.19238.36.camel@mtksdccf07> <1589334472.19238.44.camel@mtksdccf07> In-Reply-To: <1589334472.19238.44.camel@mtksdccf07> From: Dmitry Vyukov Date: Wed, 13 May 2020 08:51:27 +0200 Message-ID: Subject: Re: [PATCH v2 1/3] rcu/kasan: record and print call_rcu() call stack To: Walter Wu Cc: Andrey Ryabinin , Alexander Potapenko , Matthias Brugger , "Paul E . McKenney" , Josh Triplett , Mathieu Desnoyers , Lai Jiangshan , Joel Fernandes , Andrew Morton , kasan-dev , Linux-MM , LKML , Linux ARM Content-Type: text/plain; charset="UTF-8" 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: On Wed, May 13, 2020 at 3:48 AM Walter Wu wrote: > > > > Are you sure it will increase object size? > > > > I think we overlap kasan_free_meta with the object as well. The only > > > > case we don't overlap kasan_free_meta with the object are > > > > SLAB_TYPESAFE_BY_RCU || cache->ctor. But these are rare and it should > > > > only affect small objects with small redzones. > > > > And I think now we simply have a bug for these objects, we check > > > > KASAN_KMALLOC_FREE and then assume object contains free stack, but for > > > > objects with ctor, they still contain live object data, we don't store > > > > free stack in them. > > > > Such objects can be both free and still contain user data. > > > > > > > > > > Overlay kasan_free_meta. I see. but overlay it only when the object was > > > freed. kasan_free_meta will be used until free object. > > > 1). When put object into quarantine, it need kasan_free_meta. > > > 2). When the object exit from quarantine, it need kasan_free_meta > > > > > > If we choose to overlay kasan_free_meta, then the free stack will be > > > stored very late. It may has no free stack in report. > > > > Sorry, I don't understand what you mean. > > > > Why will it be stored too late? > > In __kasan_slab_free() putting into quarantine and recording free > > stack are literally adjacent lines of code: > > > > static bool __kasan_slab_free(struct kmem_cache *cache, void *object, > > unsigned long ip, bool quarantine) > > { > > ... > > kasan_set_free_info(cache, object, tag); > > quarantine_put(get_free_info(cache, object), cache); > > > > > > Just to make sure, what I meant is that we add free_track to kasan_free_meta: > > > > struct kasan_free_meta { > > struct qlist_node quarantine_link; > > + struct kasan_track free_track; > > }; > > > > When I see above struct kasan_free_meta, I know why you don't understand > my meaning, because I thought you were going to overlay the > quarantine_link by free_track, but it seems like to add free_track to > kasan_free_meta. Does it enlarge meta-data size? I would assume it should not increase meta-data size. In both cases we store exactly the same information inside of the object: quarantine link and free track. I see it more as a question of code organization. We already have a concept of "this data is placed inside of the freed object", we already have a name for it (kasan_free_meta), we already have code to choose where to place it, we already have helper functions to access it. And your change effectively duplicates all of this to place the free track. > > And I think its life-time and everything should be exactly what we need. > > > > Also it should help to fix the problem with ctors: kasan_free_meta is > > already allocated on the side for such objects, and that's exactly > > what we need for objects with ctor's. > > I see.