[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230124122015.9f4e93e197153183085afbff@linux-foundation.org>
Date: Tue, 24 Jan 2023 12:20:15 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Catalin Marinas <catalin.marinas@....com>
Cc: Isaac Manjarres <isaacmanjarres@...gle.com>,
Saravana Kannan <saravanak@...gle.com>,
Suren Baghdasaryan <surenb@...gle.com>,
kernel-team@...roid.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 0/2] Fixes for kmemleak tracking with CMA regions
On Tue, 24 Jan 2023 15:48:57 +0000 Catalin Marinas <catalin.marinas@....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.
Powered by blists - more mailing lists