Date:   Tue, 24 Jan 2023 12:20:15 -0800
From:   Andrew Morton <akpm@linux-foundation.org>
To:     Catalin Marinas <catalin.marinas@arm.com>
Cc:     Isaac Manjarres <isaacmanjarres@google.com>,
        Saravana Kannan <saravanak@google.com>,
        Suren Baghdasaryan <surenb@google.com>,
        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: <20230124122015.9f4e93e197153183085afbff@linux-foundation.org>
In-Reply-To: <Y8/96eIu47UfqsWO@arm.com>
References: <20230109221624.592315-1-isaacmanjarres@google.com>
        <Y8gpfgEXtialPVLk@arm.com>
        <Y8neaPB2y689WKOf@google.com>
        <Y8/96eIu47UfqsWO@arm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Tue, 24 Jan 2023 15:48:57 +0000 Catalin Marinas <catalin.marinas@arm.com> 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.
> 
> > 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.
> 
> It's not. I think it should be reverted.

Could someone please send along a patch to revert this, along
with the explanation for doing so?  And please consider a cc:stable.