From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751921AbdHBXro (ORCPT <rfc822;w@1wt.eu>);
        Wed, 2 Aug 2017 19:47:44 -0400
Received: from LGEAMRELO11.lge.com ([156.147.23.51]:55245 "EHLO
        lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751161AbdHBXrn (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 2 Aug 2017 19:47:43 -0400
X-Original-SENDERIP: 156.147.1.126
X-Original-MAILFROM: minchan@kernel.org
X-Original-SENDERIP: 10.177.220.163
X-Original-MAILFROM: minchan@kernel.org
Date: Thu, 3 Aug 2017 08:47:41 +0900
From: Minchan Kim <minchan@kernel.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Mike Galbraith <efault@gmx.de>,
        Andrew Morton <akpm@linux-foundation.org>,
        Jerome Marchand <jmarchan@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>, Nitin Gupta <ngupta@vflare.org>
Subject: Re: [zram] ltp inspired explosion  - master v4.13-rc1-3-g87b2c3fc6317
Message-ID: <20170802234741.GE32020@bbox>
References: <1500283045.7885.37.camel@gmx.de>
 <1500920221.16574.7.camel@gmx.de>
 <20170725062650.GA12134@bbox>
 <877eymsikr.fsf@concordia.ellerman.id.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <877eymsikr.fsf@concordia.ellerman.id.au>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Michael,

On Wed, Aug 02, 2017 at 02:24:20PM +1000, Michael Ellerman wrote:
> Minchan Kim <minchan@kernel.org> writes:
> > From 0ffbd3c8769fdf56e2f14908f890f9d1703ed32e Mon Sep 17 00:00:00 2001
> > From: Minchan Kim <minchan@kernel.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@redhat.com>
> > Reported-by: Mike Galbraith <efault@gmx.de>
> > Signed-off-by: Minchan Kim <minchan@kernel.org>
> > ---
> >  mm/zsmalloc.c | 1 -
> >  1 file changed, 1 deletion(-)
> 
> I just bisected this too.

Sorry for bothering you.

> 
> How about a fixes tag to help the next chump who hits it?
> 
> Fixes: cf8e0fedf078 ("mm/zsmalloc: simplify zs_max_alloc_size handling")

Thanks for good suggestion.
Andrew already did it and just sent to Linus.

Thanks, Andrew.