[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877eymsikr.fsf@concordia.ellerman.id.au>
Date: Wed, 02 Aug 2017 14:24:20 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Minchan Kim <minchan@...nel.org>, Mike Galbraith <efault@....de>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: Jerome Marchand <jmarchan@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
Nitin Gupta <ngupta@...are.org>
Subject: Re: [zram] ltp inspired explosion - master v4.13-rc1-3-g87b2c3fc6317
Minchan Kim <minchan@...nel.org> writes:
> From 0ffbd3c8769fdf56e2f14908f890f9d1703ed32e Mon Sep 17 00:00:00 2001
> From: Minchan Kim <minchan@...nel.org>
> Date: Tue, 25 Jul 2017 15:15:18 +0900
> Subject: [PATCH] zram: do not free pool->size_class
>
> Mike reported kernel goes oops with ltp:zram03 testcase.
...
>
> He bisected the problem is [1].
>
> By [1], zram doesn't use double pointer for pool->size_class any more
> in zs_create_pool so counter function zs_destroy_pool don't need to
> free it, either. Otherwise, it does kfree wrong address and then,
> kernel goes Oops.
>
> [1] cf8e0fedf078 mm/zsmalloc: simplify zs_max_alloc_size handling
>
> Cc: Jerome Marchand <jmarchan@...hat.com>
> Reported-by: Mike Galbraith <efault@....de>
> Signed-off-by: Minchan Kim <minchan@...nel.org>
> ---
> mm/zsmalloc.c | 1 -
> 1 file changed, 1 deletion(-)
I just bisected this too.
How about a fixes tag to help the next chump who hits it?
Fixes: cf8e0fedf078 ("mm/zsmalloc: simplify zs_max_alloc_size handling")
cheers
Powered by blists - more mailing lists