Re: [PATCH v1 0/2] Fixes for kmemleak tracking with CMA regions

[Isaac Manjarres <isaacmanjarres@google.com>]

On Wed, Jan 25, 2023 at 12:08:58PM +0000, Catalin Marinas wrote:
> That's an option. If there's too much churn to add a flag, an
> alternative is to use the bottom bit of 'end' to set the noleaktrace
> flag.
Using the least significant bit won't work; there are allocations for
CMA regions that can be specified to occur within the first 4 GB of
memory, and would have an alloc-ranges of [0 0xffff_ffff]. I also don't
think there's anything in the memblock documentation that ensures that
those bits are supposed to be clear all the time.

> Yet another idea is to avoid the kmemleak callback on all the 'phys'
> memblock allocations. We can add the callback to the higher level
> memblock_alloc() which returns a VA but the lower level 'phys' variants
> could simply avoid it. However, I think we still need the
> MEMBLOCK_ALLOC_NOLEAKTRACE flag for the kasan shadow allocation. Well,
> given that this flag is not widely used, we can add explicit
> kmemleak_ignore() calls in those four places.
> 
> I think the latter, if it works, would be the least intrusive.

I agree; I think using kmemleak_ignore() would be best. I will
split that into series: 1 series that fixes the kmemleak issue
with CMA regions by reverting Calvin's patch and adding a call
to kmemleak_ignore in the call-stack I referenced earlier, and
then another series that cleans up the usage of the flag.

--Isaac