On Wed, Oct 18, 2023 at 06:29:50PM +0800, Liu Shixin wrote:
> The kmemleak object is allocated by mem_pool_alloc(), which
> could be from slab or mem_pool[], so it's not suitable using
> __kmem_cache_free() to free the object, use __mem_pool_free()
> instead.
>
> Fixes: 0647398a8c7b ("mm: kmemleak: simple memory allocation pool for kmemleak objects")
> Signed-off-by: Liu Shixin <[email protected]>
Could you please reorder this patch before the previous one? If you
added a Fixes tag, we may want a cc stable as well (as for the other
patches with a Fixes tag) and it makes more sense to backport it on its
own without the __create_object() split. Otherwise:
Reviewed-by: Catalin Marinas <[email protected]>
On Wed, Oct 18, 2023 at 04:48:06PM +0100, Catalin Marinas wrote:
> On Wed, Oct 18, 2023 at 06:29:50PM +0800, Liu Shixin wrote:
> > The kmemleak object is allocated by mem_pool_alloc(), which
> > could be from slab or mem_pool[], so it's not suitable using
> > __kmem_cache_free() to free the object, use __mem_pool_free()
> > instead.
> >
> > Fixes: 0647398a8c7b ("mm: kmemleak: simple memory allocation pool for kmemleak objects")
> > Signed-off-by: Liu Shixin <[email protected]>
>
> Could you please reorder this patch before the previous one? If you
> added a Fixes tag, we may want a cc stable as well (as for the other
> patches with a Fixes tag) and it makes more sense to backport it on its
> own without the __create_object() split. Otherwise:
Ah, ignore this. If we want a cc stable, the whole thing needs
backporting, including the split which is essential for the subsequent
fix.
> Reviewed-by: Catalin Marinas <[email protected]>
--
Catalin
On Wed, 18 Oct 2023 16:57:50 +0100 Catalin Marinas <[email protected]> wrote:
> > Could you please reorder this patch before the previous one? If you
> > added a Fixes tag, we may want a cc stable as well (as for the other
> > patches with a Fixes tag) and it makes more sense to backport it on its
> > own without the __create_object() split. Otherwise:
>
> Ah, ignore this. If we want a cc stable, the whole thing needs
> backporting, including the split which is essential for the subsequent
> fix.
Do we want a cc:stable? That tag wasn't originally included.
If so, all seven patches?
If "not all seven" then can we please have two series, one for the
backport patches, one for next merge window.
On Wed, Oct 18, 2023 at 09:22:53AM -0700, Andrew Morton wrote:
> On Wed, 18 Oct 2023 16:57:50 +0100 Catalin Marinas <[email protected]> wrote:
> > > Could you please reorder this patch before the previous one? If you
> > > added a Fixes tag, we may want a cc stable as well (as for the other
> > > patches with a Fixes tag) and it makes more sense to backport it on its
> > > own without the __create_object() split. Otherwise:
> >
> > Ah, ignore this. If we want a cc stable, the whole thing needs
> > backporting, including the split which is essential for the subsequent
> > fix.
>
> Do we want a cc:stable? That tag wasn't originally included.
>
> If so, all seven patches?
>
> If "not all seven" then can we please have two series, one for the
> backport patches, one for next merge window.
I think we need all 7 if we are to backport them. But we don't need to
cc stable explicitly, we can send them to [email protected] separately
once tested on those stable versions. So, for the mm tree, don't bother
with cc stable.
--
Catalin