Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S965424AbeAKS36 (ORCPT <rfc822;ralf@linux-mips.org> + 1 other);
        Thu, 11 Jan 2018 13:29:58 -0500
Received: from mail-oi0-f46.google.com ([209.85.218.46]:36106 "EHLO
        mail-oi0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S965382AbeAKS3z (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 11 Jan 2018 13:29:55 -0500
X-Google-Smtp-Source: ACJfBovFHxelQW0XRY6es76EJKDT1O5SfkJOXFIxi8GgOZiTr/THPMaoKk9xU6LUMHVB8f1D85TK0A==
Subject: =?UTF-8?B?UmU6IOetlOWkjTog562U5aSNOiBbUEFUQ0hdIElPTjogU3lzX2hlYXA6?=
 =?UTF-8?Q?_fix_the_incorrect_pool->gfp=5fmask_setting?=
To: "Zengtao (B)" <prime.zeng@hisilicon.com>,
        Dan Carpenter <dan.carpenter@oracle.com>,
        "Chenfeng (puck)" <puck.chen@hisilicon.com>
Cc: "sumit.semwal@linaro.org" <sumit.semwal@linaro.org>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "arve@android.com" <arve@android.com>,
        "tkjos@android.com" <tkjos@android.com>,
        "maco@android.com" <maco@android.com>,
        "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <1515494623-8383-1-git-send-email-prime.zeng@hisilicon.com>
 <5A543741.9060806@hisilicon.com> <20180109091428.sewxoc7vrtox33ai@mwanda>
 <678F3D1BB717D949B966B68EAEB446ED0C83060D@DGGEMM506-MBX.china.huawei.com>
 <f1c7c53d-0c7f-e66e-2d0f-f5d12486c627@redhat.com>
 <678F3D1BB717D949B966B68EAEB446ED0C833C95@DGGEMM506-MBX.china.huawei.com>
From: Laura Abbott <labbott@redhat.com>
Message-ID: <72ba0d4b-faa2-13c1-df4b-add6aa214389@redhat.com>
Date: Thu, 11 Jan 2018 10:29:52 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <678F3D1BB717D949B966B68EAEB446ED0C833C95@DGGEMM506-MBX.china.huawei.com>
Content-Type: text/plain; charset=gbk; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Return-Path: <linux-kernel-owner@vger.kernel.org>

On 01/10/2018 06:06 PM, Zengtao (B) wrote:
>> -----?ʼ?ԭ??-----
>> ??????: Laura Abbott [mailto:labbott@redhat.com]
>> ????ʱ??: 2018??1??11?? 8:01
>> ?ռ???: Zengtao (B) <prime.zeng@hisilicon.com>; Dan Carpenter
>> <dan.carpenter@oracle.com>; Chenfeng (puck) <puck.chen@hisilicon.com>
>> ????: sumit.semwal@linaro.org; gregkh@linuxfoundation.org;
>> arve@android.com; tkjos@android.com; maco@android.com;
>> devel@driverdev.osuosl.org; linux-kernel@vger.kernel.org
>> ????: Re: ????: [PATCH] ION: Sys_heap: fix the incorrect pool->gfp_mask
>> setting
>>
>> On 01/09/2018 04:06 AM, Zengtao (B) wrote:
>>>> -----?ʼ?ԭ??-----
>>>> ??????: Dan Carpenter [mailto:dan.carpenter@oracle.com]
>>>> ????ʱ??: 2018??1??9?? 17:14
>>>> ?ռ???: Chenfeng (puck) <puck.chen@hisilicon.com>
>>>> ????: Zengtao (B) <prime.zeng@hisilicon.com>; labbott@redhat.com;
>>>> sumit.semwal@linaro.org; gregkh@linuxfoundation.org;
>>>> arve@android.com; tkjos@android.com; maco@android.com;
>>>> devel@driverdev.osuosl.org; linux-kernel@vger.kernel.org
>>>> ????: Re: [PATCH] ION: Sys_heap: fix the incorrect pool->gfp_mask
>>>> setting
>>>>
>>>> On Tue, Jan 09, 2018 at 11:30:09AM +0800, Chen Feng wrote:
>>>>>
>>>>>
>>>>> On 2018/1/9 18:43, Zeng Tao wrote:
>>>>>> This issue is introduced by the commit <e7f63771b60e> ("ION: Sys_heap:
>>>>>> Add cached pool to spead up cached buffer alloc"),
>>>>
>>>> Use the Fixes tag.
>>>>
>>>> Fixes: e7f63771b60e ("ION: Sys_heap: Add cached pool to spead up
>>>> cached buffer alloc")
>>>>
>>> Agree, thanks.
>>>
>>
>> If you're going to be fixing this, it would be good to fix the other problems
>> pointed out (stop with the #define of the flags).
>>
> It is OK, I will fix in the new version fix.
> 
> And to make the code more explicit, I have to choices of fixes:
> Choice 1:
> if (orders[i] > 4)
> 	gfp_flags = high_order_gfp_flags;
> else
> 	gfp_flags = low_order_gfp_flags;
> Choice 2:
> gfp_flags = (orders[i] > 4) ? high_order_gfp_flags : low_order_gfp_flags;
> 

I prefer #1, but please make sure you are following the
suggestions in https://marc.info/?l=linux-kernel&m=151518104214191&w=2

> Any suggestion ?
> 
> 
> BTW, I found another problem related:
> Currently the order 4 and order 0 allocation flag haven't got the __GFP_NOWARN set,
> if the order 4 allocation failed but the allocation of order 0 success, it will print warning
> message which is useless.
> 
> Of course, this is not related to this fix, but this is what I have met when test this fix.
> 

Yes, go ahead and fix that in a separate patch too.

> Thanks
> Zengtao
> 

Thanks,
Laura