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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 461E4C433EF for ; Tue, 7 Jun 2022 14:34:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B5E636B0072; Tue, 7 Jun 2022 10:34:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AE6C06B0074; Tue, 7 Jun 2022 10:34:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 987196B0075; Tue, 7 Jun 2022 10:34:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 82A146B0072 for ; Tue, 7 Jun 2022 10:34:27 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 529A0CBA for ; Tue, 7 Jun 2022 14:34:27 +0000 (UTC) X-FDA: 79551685374.18.69155B6 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by imf20.hostedemail.com (Postfix) with ESMTP id 0989C1C0068 for ; Tue, 7 Jun 2022 14:34:05 +0000 (UTC) Received: by mail-pl1-f181.google.com with SMTP id q18so14943366pln.12 for ; Tue, 07 Jun 2022 07:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=027YaoyvyAc/mF6u+WuR4wY8YjOOeIp62H/y/ouNaZs=; b=ErWhIp3PtPJCfXnP0e79ifi/G1DoBLN1q5UPlmYNENGrPgrlVce9v80iUsE/8dxGNr 1wkptiVh/a56F3VZLtI3vpl3/b16ATQLu/tC/xyM/YJZZIfgX3OH74C50Zi6f1YZfFE9 sYoNvbQjvs6zvtqj3oK9Nb9WXjFlSv2HsfRXowaKpPUttiZR9fMrpDSnXpDpfzTlVcvP YmnOk7kI0cYuqq0cNpOtlw7cL+ahavPS6aPVxLFbrwpcHPbaYJdI9x/mb9Nidn8kLouB DOu83Te+9TfRgY22rMOb+r35a/5vZFufbjUm/V79X+moCIL3DPa2YsN89WGpI1PN8PdE gvxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=027YaoyvyAc/mF6u+WuR4wY8YjOOeIp62H/y/ouNaZs=; b=1NrqFXytWWvtSErwY4Prh2LV7XDPtOlcZLL0lg67EI3rogM80vpYJFeUkTSS6atX8h jRPvRfXRYEBS/2cMRfyW1K6PvBBK0zg+u2rzig+WSt2xslSHGpEtSGnNSu6frLLi9nCp pzluXo8VNPUtw78GCAHzF71wajZnDPaeIU0+xo6SIPDczFgiCqAOaVlCLcNB/uRFRpN4 HdqrqpjGMln/lbk/RxzAfbpS3ZJ7I8NQf1JCPzglVXpgu0fav0wHZgzUjEeWWPGcroTI RSyxX5H+X7FAVQJt2KMkgeAlKwe9ZfB9vxXNZyBHF+iNUotb2B/Lcc/5Sy+qcqAywfeh b5vQ== X-Gm-Message-State: AOAM531ktL8WgG/9ayP/4W5Z81utR36/keZfMk3IO0dygQISJZVbnU/z Ljj/f3+6Etv2eBzvbTFWi8M= X-Google-Smtp-Source: ABdhPJyBPsIB0n1eKeyLa/KeHNHto49csAeUIQI6A7XmIPBbbFTKyDK7sab46/904rekquLmSzX/aA== X-Received: by 2002:a17:90b:4ccf:b0:1ea:264c:7c0c with SMTP id nd15-20020a17090b4ccf00b001ea264c7c0cmr873033pjb.176.1654612465872; Tue, 07 Jun 2022 07:34:25 -0700 (PDT) Received: from [192.168.1.104] ([101.86.206.159]) by smtp.gmail.com with ESMTPSA id je21-20020a170903265500b00163b02822bdsm12533885plb.160.2022.06.07.07.34.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jun 2022 07:34:25 -0700 (PDT) Message-ID: Date: Tue, 7 Jun 2022 22:34:21 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v2 2/4] mm: kmemleak: add rbtree for objects allocated with physical address Content-Language: en-US To: Catalin Marinas Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, yee.lee@mediatek.com References: <20220603035415.1243913-1-patrick.wang.shcn@gmail.com> <20220603035415.1243913-3-patrick.wang.shcn@gmail.com> From: Patrick Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 0989C1C0068 X-Stat-Signature: 1q7c4ry7dsfz1yjk1snj3szu66xfjris X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ErWhIp3P; spf=pass (imf20.hostedemail.com: domain of patrick.wang.shcn@gmail.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=patrick.wang.shcn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam08 X-HE-Tag: 1654612445-683369 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 2022/6/6 22:38, Catalin Marinas wrote: > On Fri, Jun 03, 2022 at 11:54:13AM +0800, Patrick Wang wrote: >> @@ -536,27 +543,32 @@ static struct kmemleak_object *find_and_get_object(unsigned long ptr, int alias) >> } >> >> /* >> - * Remove an object from the object_tree_root and object_list. Must be called >> - * with the kmemleak_lock held _if_ kmemleak is still enabled. >> + * Remove an object from the object_tree_root (or object_phys_tree_root) >> + * and object_list. Must be called with the kmemleak_lock held _if_ kmemleak >> + * is still enabled. >> */ >> static void __remove_object(struct kmemleak_object *object) >> { >> - rb_erase(&object->rb_node, &object_tree_root); >> + rb_erase(&object->rb_node, object->flags & OBJECT_PHYS ? >> + &object_phys_tree_root : >> + &object_tree_root); > > This pattern appears in a few place, I guess it's better with a macro, > say get_object_tree_root(object). But see how many are left, I have some > comments below on reducing the diff. Will do. > >> @@ -709,12 +724,12 @@ static void delete_object_full(unsigned long ptr) >> * delete it. If the memory block is partially freed, the function may create >> * additional metadata for the remaining parts of the block. >> */ >> -static void delete_object_part(unsigned long ptr, size_t size) >> +static void delete_object_part(unsigned long ptr, size_t size, bool is_phys) >> { >> struct kmemleak_object *object; >> unsigned long start, end; >> >> - object = find_and_remove_object(ptr, 1); >> + object = find_and_remove_object(ptr, 1, is_phys); >> if (!object) { >> #ifdef DEBUG >> kmemleak_warn("Partially freeing unknown object at 0x%08lx (size %zu)\n", > > The previous patch introduced a check on object->flags for > delete_object_part(). I think you can just use is_phys directly now when > calling create_object(). Will do. > >> @@ -1275,7 +1290,7 @@ static void scan_block(void *_start, void *_end, >> * is still present in object_tree_root and object_list >> * (with updates protected by kmemleak_lock). >> */ >> - object = lookup_object(pointer, 1); >> + object = lookup_object(pointer, 1, false); >> if (!object) >> continue; >> if (object == scanned) >> @@ -1299,7 +1314,7 @@ static void scan_block(void *_start, void *_end, >> raw_spin_unlock(&object->lock); >> >> if (excess_ref) { >> - object = lookup_object(excess_ref, 0); >> + object = lookup_object(excess_ref, 0, false); >> if (!object) >> continue; >> if (object == scanned) >> @@ -1728,7 +1743,7 @@ static int dump_str_object_info(const char *str) >> >> if (kstrtoul(str, 0, &addr)) >> return -EINVAL; >> - object = find_and_get_object(addr, 0); >> + object = find_and_get_object(addr, 0, false); >> if (!object) { >> pr_info("Unknown object at 0x%08lx\n", addr); >> return -EINVAL; > > I think find_and_get_object() is never called on a phys object, so you > can probably simplify these a bit. Just add an is_phys argument where > strictly necessary and maybe even add a separate function like > lookup_object_phys() to reduce the other changes. Will add lookup_object_phys() function and find_and_get_object_phys() function. The find_and_get_object() function is also called in many places. Thanks, Patrick