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 B97A6C004D4 for ; Fri, 20 Jan 2023 00:21:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 318A26B0071; Thu, 19 Jan 2023 19:21:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C94A6B0072; Thu, 19 Jan 2023 19:21:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 190436B0074; Thu, 19 Jan 2023 19:21:05 -0500 (EST) 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 05B916B0071 for ; Thu, 19 Jan 2023 19:21:05 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C1F36AB2D5 for ; Fri, 20 Jan 2023 00:21:04 +0000 (UTC) X-FDA: 80373272448.25.94C28B1 Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) by imf10.hostedemail.com (Postfix) with ESMTP id EDE81C0006 for ; Fri, 20 Jan 2023 00:21:02 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=iSDvWSA5; spf=pass (imf10.hostedemail.com: domain of isaacmanjarres@google.com designates 209.85.215.172 as permitted sender) smtp.mailfrom=isaacmanjarres@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674174063; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5QyhsRn5OPstDd8tOopiUECeAKD2qFv3oS+wtxEl1Qw=; b=FQwVJIi1j55bE3p6dWbpNxSgsgnsEycAnS/YZIHy6YVYq83v0ytVo2WwMaZC+TbaX035uf gomNoYqxuGGOpGHCSgGg0DU+Hypr30eVuaumXELgEHPclT9HtMYtoc00wOdjDK8dTs02qH hL+sCoRrCepBiRCiEsSM25t0fEWG4s4= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=iSDvWSA5; spf=pass (imf10.hostedemail.com: domain of isaacmanjarres@google.com designates 209.85.215.172 as permitted sender) smtp.mailfrom=isaacmanjarres@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674174063; a=rsa-sha256; cv=none; b=L2NmkVC1U9ixJbfXPmVCRo20auXKjhqTwZ72efcEdJhBD9nrIdARIAKLolBf3vm4IoL5Kb W56MzSbkl5Zr1+EwrwdD+s14zNVxGAZ1XMuzOxtyzMITmv1Pz46ChQobdMOladt5rwc9B1 LVGOegbpJzTAZjo3WwNvfbnboE5E+rw= Received: by mail-pg1-f172.google.com with SMTP id e10so2918342pgc.9 for ; Thu, 19 Jan 2023 16:21:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=5QyhsRn5OPstDd8tOopiUECeAKD2qFv3oS+wtxEl1Qw=; b=iSDvWSA5rlBU7hsDYZ2sJL2EwYssyRlC/LewAV1ffm1T686pJ2LTtUq+NiKA0sjI17 hz6T1psf7ed69X932TEhFFdJ0iePUhfZVV6vcZIj3cGj0SOyACbSpOGIpPba5pX4LOUt lV2CXp9GEVZBQyh+KbdjavIlNAEXBByvqJyxHLx5HA/i+8f/njc2az/QhlRUIMcgM52I Q2s7e+V2UtCQMcQD1RVYnzj9xWvAj81wB03ANBKXDUqsCPQyITghZXPjFCOp9TK8FccS KOQU5NsJQZmQnUT2y8Vp2vZBjGIyvaw+za7JRZRgPKTa9WOBzsmswqG5+dhUrIRftcW2 SN5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5QyhsRn5OPstDd8tOopiUECeAKD2qFv3oS+wtxEl1Qw=; b=zZsdv83pJXCPjyzffkXKfXb6WB01nNsmW60WHJllQQpEKbbY/7yibboVEjiWi6c50c EpGTXm6PN/VcmUOwWmE5vgNgbuNkzbA0OVzH3nYQjv0eXohJ4UxA23/TQIQhkN76fnr6 sywgS4fIvZUuI/5lqHKxbchpggPUdVagPdZ0AfqG3JhKKVq6suIglBTcCd+nczl+inom g1oUngQ4Qxc6UEa0GIeVFb+b+FOGsUcX1dTZ1BnzexkXfAhRLAIJ3VkROxJQTq0WuN9C 8/yTYQrrKacEnnQnMDhCiE9+OQ14MFCrb6j6YuQGDH4SDIq3EjgUktkk3p5j0V7I7grc 5omw== X-Gm-Message-State: AFqh2kqYCjiz4vAar23xK469Dd4spaoH5I0OhPnIFDuO/MwboqJoy5jv gdx8FPMdWGWCwn1IDMqGQfMmZQ== X-Google-Smtp-Source: AMrXdXvfMAk2TbpKh3xyvFhXLjdqCJ0E+tq3u6ok0HR1zHtXrR8ifCiqUX+fx2d0WT/n2ROp+SiIdQ== X-Received: by 2002:a62:2783:0:b0:581:bfac:7a52 with SMTP id n125-20020a622783000000b00581bfac7a52mr37335pfn.1.1674174061385; Thu, 19 Jan 2023 16:21:01 -0800 (PST) Received: from google.com ([2620:15c:2d:3:6cb1:c443:b416:7d4d]) by smtp.gmail.com with ESMTPSA id z4-20020aa79484000000b005823b7da05asm9308122pfk.122.2023.01.19.16.21.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Jan 2023 16:21:00 -0800 (PST) Date: Thu, 19 Jan 2023 16:20:56 -0800 From: Isaac Manjarres To: Catalin Marinas Cc: Andrew Morton , Saravana Kannan , Suren Baghdasaryan , kernel-team@android.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 0/2] Fixes for kmemleak tracking with CMA regions Message-ID: References: <20230109221624.592315-1-isaacmanjarres@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: EDE81C0006 X-Rspam-User: X-Stat-Signature: 7nip4cca88z7wa56s1gaknmubutnjk3q X-HE-Tag: 1674174062-943466 X-HE-Meta: U2FsdGVkX19ihStfpcmJX+4VxF6AtOvpKNCsHdhfe1QUFbWlae052B22ecJfb44lAZWBba+ebj7rTWXbrODqXV35cVF6cHl54y5ZGwdZVwloQDJ49g52giUuedoVZceeyV6O8R0Xn16xpDsVelzherkar379JXQOkoFmreo4cqdYywu7Kh1ZSWQNGBkyrcwxb8iUrjJN17sunW/RDaSEDpTCTNoqem6ZIfLdZY26eBKZBRMnh+Qb6PHsp+OR87curcxS0bmGq20ZddkdbVRGw456ZLxrT4M/rkBjJSJRzoiMvmKgY4PEETrKwZYourp1X3RtV0tV2E/wVJmaYtFgFz/p32mKs8DD+Alf9bWDk0yjLgwMiATzvEY1jTbCl+9MyDJdQDxXMyj5+S0MIsSnENLxkvubzb3eKchCTybOter96fWahx21yReBtoPU/qqlvv1V+eXZbPtyD0ABSOpQ9kx4D0FthwML/w18xjJwIycdqflYpp+hX6kKzMN6PIbN0DKquWHqgpMnHMqG7lXbS7Xm3e00h2jcCRyBFoLHRU73UYOfyb5E3PMX5DvONCJVFn25LDCjSvK9eq51nV6MZMms8vv9lGbfbd1BYb+JFBl75KyFAHFL7XxRshH1Bkslt1DZIPnpzEuljMCDd5rWzI5+XlxY8DRhReB0yTdQzEJFn/wfWZj56UGBJ7I/00H4OSDjwx7GK4kMyZ8u3j8AA3UydX4a6o8vUNxFy7BlOiT0vo9E2PbvpMQaNx955fn8BE3H1N5IeJpa4MtefwyrOic2UGzKqR5ZsDZkDWujbhqz0M8OWK0jM3K4x20IdDnDGajWq4fmngpA6kyW4eycXSA1rvTAQPu/Jp+9rN+8jYD76HNf/KsixxhnDfI7oGrgU0gH/FU/F7TxnzR5czpn8DpTwCEy3yUKeIIWcPMXpkC3YibC9D+ehZkSruoX8GrIsJKKG8qRnvi7Jn6CmH7 bBYYU3qe bGPoW4Awh2Hyw4Q7zvaNBc+9J0L+gFWE4kQmaTOYDGRdON7OT1s16YaW4tkDsYILX3qgkzhapwJLdXk0mJmAP/x3FzqxeCqHZv7UJQOJjF7297Y2ffo2pLcK+UCCnFNvlSPrrIpHeqWL2DxY+VuTVE5SspuXcoH1U3hdWtVAMtKIUsBZKRQi6QCBAa3jmRiY2K1TThDMUNAehgzyvVzCxalBwM6a1ZfYCkm0w7xTTer6U0j//h5wscsmQRTVgFOo0bPMMjqBQ/jjTycR5gvo7C43uibhrf73vldQp97HFEKixDqutEIwQq4qakuCPevbCDhBofCCD5J+94qfSV8KXqBMP8Zp1F1FZ2JehfKdV0TjMBDK8yDY7QYpuPXSfK73pIJREJOmFzwown+K2toAxtlwCHZyZp7e2suWPSByw7r6ncJ8FxjHzbppEHMM7409YqxNU 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, Jan 18, 2023 at 05:16:46PM +0000, Catalin Marinas wrote: > Hi Isaac, > > Please cc me on kmemleak patches. I only noticed when Andrew picket them > up. Will do, sorry about that. > > What I don't understand is why kmemleak scans such CMA regions. The only > reason for a kmemleak_ignore_phys() call in cma_declare_contiguous_nid() > is because the kmemleak_alloc_phys() hook was called on the > memblock_alloc_range_nid() path, so we don't want this scanned. The reason is because kmemleak_ignore_phys() is only called within cma_declare_contiguous_nid(), which is not called for every CMA region. For instance, CMA regions which are specified through the devicetree and not constrained to a fixed address are allocated through early_init_dt_alloc_reserved_memory_arch(), which eventually calls kmemleak_alloc_phys() through memblock_phys_alloc_range(). When the CMA region is constrained to a particular address, it is allocated through early_init_dt_reserve_memory(), which is followed up by a call to kmemleak_alloc_phys() due to this commit: https://lore.kernel.org/all/20211123090641.3654006-1-calvinzhang.cool@gmail.com/T/#u I'm not sure if that commit is appropriate, given that reserved regions that still have their direct mappings intact may be used for DMA, which isn't appropriate for kmemleak scanning. In any one of these cases, the kmemleak object is never removed, nor is kmemleak told to ignore it, so it ends up scanning it later. > Do you have a backtrace? Yes: [ 61.155981][ T97] Unable to handle kernel paging request at virtual address ... [ 61.156241][ T97] Hardware name: Oriole EVT 1.1 (DT) [ 61.156243][ T97] pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 61.156246][ T97] pc : scan_block+0xbc/0x3c8 [ 61.156253][ T97] lr : scan_block+0xac/0x3c8 [ 61.156291][ T97] Call trace: [ 61.156293][ T97] scan_block+0xbc/0x3c8 [ 61.156296][ T97] scan_gray_list+0x130/0x23c [ 61.156299][ T97] kmemleak_scan+0x408/0x71c [ 61.156302][ T97] kmemleak_scan_thread+0xc0/0xf0 [ 61.156306][ T97] kthread+0x114/0x15c [ 61.156311][ T97] ret_from_fork+0x10/0x20 when I looked at the PTE from the page table walk, I saw that the virtual address mapped to the physical address within a CMA region, and that the page was unmapped (because of CONFIG_DEBUG_PAGEALLOC). > kmemleak would only scan such objects if it knows about them. So I think > it's only the case where CMA does a memblock allocation. The > kmemleak_ignore_phys() should tell kmemleak not to touch this region but > it's probably better to just free it altogether (i.e. replace the ignore > with the free kmemleak callback). Would this be sufficient for your > scenario? I agree that freeing the kmemleak object is a better strategy. However, replacing the call to kmemleak_ignore_phys() wouldn't be sufficient, as there are other scenarios that would still leave behind kmemleak objects to be scanned. That's why I ended up freeing the kmemleak object in a path that is common for all CMA areas. > I may be missing something but I don't get why kmemleak needs to be > informed only to tell kmemleak shortly after to remove them from its > list of objects. That's a good point, and I agree that it's pointless; ideally whatever way the CMA region is allocated would not inform kmemleak, and we wouldn't have to deal with kmemleak. We could use a flag like MEMBLOCK_ALLOC_NOLEAKTRACE to tell memblock to skip the call to kmemleak_alloc_phys(), but that wouldn't work as is, since MEMBLOCK_ALLOC_NOLEAKTRACE is meant to be used as the "end" parameter for memblock_alloc() and friends. For CMA regions "end" can be used (e.g. the case where the CMA region is supposed to be within a certain range). Perhaps we should change memblock to take MEMBLOCK_ALLOC_NOLEAKTRACE as a flag under a "flags" argument instead? --Isaac