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 34F2DC54EED for ; Tue, 24 Jan 2023 21:20:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B1EA06B0071; Tue, 24 Jan 2023 16:20:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ACEA76B0072; Tue, 24 Jan 2023 16:20:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 996726B0073; Tue, 24 Jan 2023 16:20: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 895E66B0071 for ; Tue, 24 Jan 2023 16:20:05 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5D6681201C4 for ; Tue, 24 Jan 2023 21:20:05 +0000 (UTC) X-FDA: 80390960370.24.104ECF2 Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by imf27.hostedemail.com (Postfix) with ESMTP id 778E240019 for ; Tue, 24 Jan 2023 21:20:03 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=WTNrPifp; spf=pass (imf27.hostedemail.com: domain of isaacmanjarres@google.com designates 209.85.216.47 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=1674595203; 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=OBxYXf9XQKgQ+wbszOVA6b3m7kHIkaxtHTOSxwRTgZI=; b=2LOtO2gCBxrUAxVTkVi7K22jLfv4Vbcxasg6MZetTfiQd9F7aN9HJ4hJtfRZudE76/k+9S sCW35+90tqPMVq1dtldg7O6T7Ntp6YfXJbpwc72olurxj51FuiDpZpmcx3NNsQ0qLook0g 9Y77IGdtsJmpyxR9GAGJDFcDZdQZ+do= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=WTNrPifp; spf=pass (imf27.hostedemail.com: domain of isaacmanjarres@google.com designates 209.85.216.47 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=1674595203; a=rsa-sha256; cv=none; b=iTn8TQTmUFtXOQKEq0oImqWVIy9AAvVvgf9JYqym3XmPZ6IodCvt1pSnmHYa5poWTq590E STaKvoNkAbVcRz5WpTMqJ5xFBlbg1aaDnrQx2giG9r+SK7tZsLyr2U8IiVFOD7eBlKcIC9 TLyoWyMqyuuQy1/ujrbQpoLQ7h356hA= Received: by mail-pj1-f47.google.com with SMTP id v6-20020a17090ad58600b00229eec90a7fso2512770pju.0 for ; Tue, 24 Jan 2023 13:20:03 -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=OBxYXf9XQKgQ+wbszOVA6b3m7kHIkaxtHTOSxwRTgZI=; b=WTNrPifpA1xZC9rsK9aKpgWZhNP9vDDNuhSBHRGYbNZGqym2iqnnzc/etpIYKjSied 3IWGHZGxPvNGBP0IOl/e9vy5pH6s7+wX0y0ZAFEFozZb2s4TZckzqxUgY44qfiFddtS4 CIVDKk2KTUuepqvFp5DRQ7G3OOVEx+vS6MMrgA0V28ZZ1CWmCVPidIq3DNbj4Qs215qw JrY8nhxugqzaaWaXJMbjiqnco1BsOVtZD5cD028B4PNXwd6GPG9tAQTFGmCcw0wIhjSH MuCAyVqaoF7+MVSAr2ejQPglXtipsJe9YRDSH3PJ2UYdG9q+ZDT9+91REQDBHAlZDR1C FsCg== 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=OBxYXf9XQKgQ+wbszOVA6b3m7kHIkaxtHTOSxwRTgZI=; b=5Kv2VIGYXCYcjW4QnDOT14twK37eZB6GqtjSt3L/Nhl01PdGcOUUYHQgKIFu+8ePLi 67y4n7YPXqlwT5xwYn/FmM0gSj7XtO3MzOwLYZWCnOJTUz5AP6O11BS0HlmS3GOeysK8 DwHYKg3DON8uEcuwYOXRo8xi/mJVyLFxtcsrYyCHW5n+QnTHqHxW3z5Aen2Z0JUes6Gs 5OnHc+pFDQfL3156yp9rt5AqtQC20WogT5mIHM45Z82204KeTPWSnknhaa82tpOyOzxe IKF3ZHXkRxsqjPziEBpU4S0uyAjqdOd1K2x4OQDt2W3kmA2fP9otibOgxdxSa0Tm7qYN yqjg== X-Gm-Message-State: AO0yUKVqk5M8zqX+pFw6XO0nZtq7Ap9w6tbH9O9DTK0YGQbFzjJ2yASp SA+FpMZAnQyL6BD3PqDc90K+Kg== X-Google-Smtp-Source: AK7set9wh5O2XAdu9rmI1KvS2VWwgf5eHBuZHh/IwPFhtV3HwjOBCkugj/VEbmqZb2xkQGz6PpitVA== X-Received: by 2002:a05:6a20:8f1a:b0:b8:c646:b0e2 with SMTP id b26-20020a056a208f1a00b000b8c646b0e2mr442277pzk.3.1674595202115; Tue, 24 Jan 2023 13:20:02 -0800 (PST) Received: from google.com ([2620:15c:2d:3:b15:b561:51fb:73c3]) by smtp.gmail.com with ESMTPSA id c32-20020a17090a492300b002265ddfc13esm8868770pjh.29.2023.01.24.13.20.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Jan 2023 13:20:01 -0800 (PST) Date: Tue, 24 Jan 2023 13:19:57 -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-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 1sd4jgdcc61rytjrbe73kbx3qf79sg3a X-Rspamd-Queue-Id: 778E240019 X-HE-Tag: 1674595203-436435 X-HE-Meta: U2FsdGVkX1+seRsW7eJjCG91FDlFVOBSrvmoAiYMWLjIlinE/lEHF/w/OW6pQ0Qvh6BeYvIl1ETBoCQhj+hVVqbmjaIhkilbcTTOFRpOQrj4Z/zCsoTvhDKoPWiEglvgCeBBsy23eX65yGN5gPIyzacy9rOE4mZIYR1N9r8F4Lmf2H6dmo5sqWps7hw/Odov8PYRmMtpFhgaGWjt+teenq6Ys6BTBCgaAmms+4VBk0zr6zBBLZ6mVvOFICQqGT5zm+VuDrkzXiuF3uaNf9dF0ZsNI/4aTMadBCdDT4OWo6+DRqdWSn5SK4PyjGX4qlNMKT/VV9lWH0TNal2dFE1pbqSVnw7asD8wVZCHPLyOq8CdUVggAvEctSfv5nt3I3MUu5rLz7+XJTIRS9gi8HIm8arM+9uvAQzHWMYljfwkeoo5GgLgaigvFapJpR7EzygB6IwO8c+A/+Bly0/pMFi0bP/P4mJvewIroe1AT37UTIt1PCE1Okc172rIy8H3XKGFcr/46pQGGhVCOmcw2yZZaaV4/fuigKqtOageZHILfKQLQ/gakv1MQ5Zzp3kWAONyFJZSO3cRkLhU8a0IqrwMtAHN0cUau3TGokP3S0OOytBVbE0Y4qpNqGnBJ2DE4Mhd+uOF7qhfAqF5dYC2g9LTcvXvfMUz4kxisra9v5mcKYLKnugpwPb08dKF7NtexVH120BosK/il7HOxe0v6aqeCsAsafMIted/N5JgdVX5ph38wGn+rejY6JV9AHECGKRH4rnHs3JMqJxDaG/EXVhwjJfJ2np5pFbCMKGFHScPLHjO10kUHsEvCyEmYNaxkVwi7SWftZbrU32h4BM6NexKDHrXTyX8m5Bv7znpA6y940zQSxfGi2JZNjO4udjpPg9Ttn4dPT52VhredrjX15948qYeH/rmB33yiPsbR36jCUCWhtZRhtw03wDK0kpV/xu5ZVoXAWF7fupQeSmPc+k ZaWklymx Cjo/yQQx0uOnoDrnMeNubApMtC1/biot+FMcsBXJdjE+T4PQI+SFIw4GBxWNnSUXFJ4cjY+XN8u1M5gvCoSa233oh0RZmdzxZ9x1XwlP2wkA3eTxJ4GbTzIdYkx5uPsKjufzIP3GVEW3jfZNpZ3W7X0aoesl2/TFKhkpW5o6vQwkdmgq/xKl1xdlDx+uv5vO/MLQc3qZXjXRu0J9dZ3G/OZlVZKWaSW1c/crZOD8pa5EIlPECIxkIHOCx3paEdn17wndv90AJdlLNHFoGOhoAIXb2/1Ntqnj3fNoFfBoukTS9vPpDxThtZJ3ElLRuopqH7bm4I4Vej0c9OIN6CJySCVR5Kd4OBUBLt+pPlYUFQI6lZco= 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 Tue, Jan 24, 2023 at 03:48:57PM +0000, Catalin Marinas wrote: > Thanks for digging this out. This patch shouldn't have ended up upstream > (commit 972fa3a7c17c "mm: kmemleak: alloc gray object for reserved > region with direct map"). I thought both Calvin Zhang and I agreed that > it's not the correct approach (not even sure there was a real problem to > fix). > > Do you still get the any faults with the above commit reverted? I'd > prefer this if it works rather than adding unnecessary > kmemleak_alloc/free callbacks that pretty much cancel each-other. Yes, I still see the same problem after reverting that commit. The problem still persists because there are CMA areas that are allocated through memblock_phys_alloc_range(), which invokes kmemleak_alloc_phys(). The allocation call stack is along the lines of: kmemleak_alloc_phys() memblock_alloc_range_nid() memblock_phys_alloc_range() __reserved_mem_alloc_size() fdt_init_reserved_mem() I also followed up on my suggestion about adding a flags parameter to the memblock allocation functions to be able to use MEMBLOCK_ALLOC_NOLEAKTRACE in this particular scenario, but that would involve changing many call-sites, which doesn't make much sense given that there are only 4 call-sites that actually use this flag. Maybe adding a new memblock allocation function that allows this flag to be passed as just a flag can be used to avoid creating these kmemleak objects for CMA allocations? --Isaac