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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 15EA1C4727E for ; Mon, 28 Sep 2020 14:16:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 989E52076A for ; Mon, 28 Sep 2020 14:16:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 989E52076A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1A0CA8E0001; Mon, 28 Sep 2020 10:16:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 150566B0068; Mon, 28 Sep 2020 10:16:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 066188E0001; Mon, 28 Sep 2020 10:16:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0135.hostedemail.com [216.40.44.135]) by kanga.kvack.org (Postfix) with ESMTP id E25366B0062 for ; Mon, 28 Sep 2020 10:16:54 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 987928249980 for ; Mon, 28 Sep 2020 14:16:54 +0000 (UTC) X-FDA: 77312671548.19.cause90_271628c27182 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id 540CB1ACC22 for ; Mon, 28 Sep 2020 14:16:54 +0000 (UTC) X-HE-Tag: cause90_271628c27182 X-Filterd-Recvd-Size: 4080 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Mon, 28 Sep 2020 14:16:53 +0000 (UTC) Received: from gaia (unknown [31.124.44.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 51DDC2075A; Mon, 28 Sep 2020 14:16:51 +0000 (UTC) Date: Mon, 28 Sep 2020 15:16:48 +0100 From: Catalin Marinas To: "chenjun (AM)" Cc: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "akpm@linux-foundation.org" , "Xiangrui (Euler)" , "weiyongjun (A)" Subject: Re: [PATCH -next 3/5] mm/kmemleak: Add support for percpu memory leak detect Message-ID: <20200928141643.GB27500@gaia> References: <20200921020007.35803-1-chenjun102@huawei.com> <20200921020007.35803-4-chenjun102@huawei.com> <20200922095736.GB15643@gaia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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 Mon, Sep 28, 2020 at 02:08:29PM +0000, chenjun (AM) wrote: > On Mon, Sep 21, 2020 at 02:00:05AM +0000, Chen Jun wrote: > > From: Wei Yongjun > >> @@ -651,6 +672,19 @@ static void create_object(unsigned long ptr, size_t size, int min_count, > >> raw_spin_unlock_irqrestore(&kmemleak_lock, flags); > >> } > >> > >> +static void create_object(unsigned long ptr, size_t size, int min_count, > >> + gfp_t gfp) > >> +{ > >> + __create_object(ptr, size, min_count, 0, gfp); > >> +} > >> + > >> +static void create_object_percpu(unsigned long ptr, size_t size, int min_count, > >> + gfp_t gfp) > >> +{ > >> + __create_object(ptr, size, min_count, OBJECT_PERCPU | OBJECT_NO_SCAN, > >> + gfp); > >> +} > >> + > >> /* > >> * Mark the object as not allocated and schedule RCU freeing via put_object(). > >> */ > >> @@ -912,10 +946,12 @@ void __ref kmemleak_alloc_percpu(const void __percpu *ptr, size_t size, > >> * Percpu allocations are only scanned and not reported as leaks > >> * (min_count is set to 0). > >> */ > >> - if (kmemleak_enabled && ptr && !IS_ERR(ptr)) > >> + if (kmemleak_enabled && ptr && !IS_ERR(ptr)) { > >> for_each_possible_cpu(cpu) > >> create_object((unsigned long)per_cpu_ptr(ptr, cpu), > >> size, 0, gfp); > >> + create_object_percpu((unsigned long)ptr, size, 1, gfp); > >> + } > >> } > > > > A concern I have here is that ptr may overlap with an existing object > > and the insertion in the rb tree will fail. For example, with !SMP, > > ptr == per_cpu_ptr(ptr, 0), so create_object() will fail and kmemleak > > gets disabled. > > > > An option would to figure out how to allow overlapping ranges with rb > > tree (or find a replacement for it if not possible). > > > > Another option would be to have an additional structure to track the > > __percpu pointers since they have their own range. If size is not > > relevant, maybe go for an xarray, otherwise another rb tree (do we have > > any instance of pointers referring some inner member of a __percpu > > object?). The scan_object() function will have to search two trees. > > I would like to use CONFIG_SMP to seprate code: > if SMP, we will create some objects for per_cpu_ptr(ptr, cpu) and an > object with OBJECT_NO_ACCESS for ptr. > if !SMP, we will not create object for per_cpu_ptr(ptr,cpu), but an > object without OBJECT_NO_ACCESS for ptr will be created. > What do you think about this opinion. The !SMP case was just an example. Do you have a guarantee that the value of the __percpu ptr doesn't clash with a linear map address? -- Catalin