From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751380AbbKYPU2 (ORCPT ); Wed, 25 Nov 2015 10:20:28 -0500 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:40251 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750832AbbKYPU0 (ORCPT ); Wed, 25 Nov 2015 10:20:26 -0500 X-Original-SENDERIP: 156.147.1.151 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 165.244.98.76 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Thu, 26 Nov 2015 00:20:25 +0900 From: Minchan Kim To: Sergey Senozhatsky CC: Andrew Morton , linux-kernel@vger.kernel.org, Kyeongdon Kim Subject: Re: [PATCH v2 3/3] zram: pass gfp from zcomp frontend to backend Message-ID: <20151125152025.GB12747@bbox> References: <1448430673-10766-1-git-send-email-minchan@kernel.org> <1448430673-10766-3-git-send-email-minchan@kernel.org> <20151125124647.GA525@swordfish> <20151125135020.GA12747@bbox> <20151125150449.GA579@swordfish> MIME-Version: 1.0 In-Reply-To: <20151125150449.GA579@swordfish> User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB03/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2015/11/26 00:20:24, Serialize by Router on LGEKRMHUB03/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2015/11/26 00:20:24, Serialize complete at 2015/11/26 00:20:24 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 26, 2015 at 12:04:49AM +0900, Sergey Senozhatsky wrote: > Hello, > > On (11/25/15 22:50), Minchan Kim wrote: > [..] > > > I think that applying 3/3 before 2/3 will be a simpler (and probably a better) > > > thing to do. We fitst extend zcomp interface and pass flags (without any > > > functional change) and then extend the flags and introduce vmalloc fallback. > > > > The reason I ordered such way is that I wanted to discuss [2/3] as > > stable material after I get your ACK. It solves real problem in android platform > > which is real fact and I think it's enough small to send stable tree. > > What do you think? > > > > > > > > So we don't have to add comments to lz4/lzo backend that are getting (re-)moved > > > in the very next commit. > > > > Fair enough if you don't agree sending [2/3] to stable. > > Aha, I see. I don't mind to send it to -stable (with __GFP_HIGHMEM fix > up). Sure. Can I add your acked-by for [2/3] and [3/3]? And I will keep order and add stable mark in [2/3]. > > Do -stable guys take this type of patches? I think so because it's real problem fix and enough small to backport. Thanks.