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 S932688AbcGKTBH (ORCPT <rfc822;w@1wt.eu>);
	Mon, 11 Jul 2016 15:01:07 -0400
Received: from out1134-251.mail.aliyun.com ([42.120.134.251]:19603 "EHLO
	out1134-251.mail.aliyun.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S932489AbcGKTBF (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 11 Jul 2016 15:01:05 -0400
X-Greylist: delayed 315 seconds by postgrey-1.27 at vger.kernel.org; Mon, 11 Jul 2016 15:01:05 EDT
X-Alimail-AntiSpam: AC=CONTINUE;BC=0.07713411|-1;FP=0|0|0|0|0|-1|-1|-1;HT=e02c03305;MF=chengang@emindsoft.com.cn;NM=1;PH=DS;RN=10;RT=10;SR=0;TI=SMTPD_----50FsESU_1468263324;
Message-ID: <5783ED17.9010805@emindsoft.com.cn>
Date: Tue, 12 Jul 2016 03:01:43 +0800
From: Chen Gang <chengang@emindsoft.com.cn>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Dave Hansen <dave.hansen@linux.intel.com>, akpm@linux-foundation.org,
        benh@kernel.crashing.org, paulus@samba.org
CC: mpe@ellerman.id.au, tglx@linutronix.de, mingo@kernel.org,
        linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
        Chen Gang <gang.chen.5i5j@gmail.com>
Subject: Re: [PATCH] include: mman: Use bool instead of int for the return
 value of arch_validate_prot
References: <1468081751-9468-1-git-send-email-chengang@emindsoft.com.cn> <5782DEA5.600@linux.intel.com>
In-Reply-To: <5782DEA5.600@linux.intel.com>
Content-Type: text/plain; charset=UTF-8
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


On 7/11/16 07:47, Dave Hansen wrote:
> On 07/09/2016 09:29 AM, chengang@emindsoft.com.cn wrote:
>> -static inline int arch_validate_prot(unsigned long prot)
>> +static inline bool arch_validate_prot(unsigned long prot)
>>  {
>>  	if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM | PROT_SAO))
>> -		return 0;
>> -	if ((prot & PROT_SAO) && !cpu_has_feature(CPU_FTR_SAO))
>> -		return 0;
>> -	return 1;
>> +		return false;
>> +	return (prot & PROT_SAO) == 0 || cpu_has_feature(CPU_FTR_SAO);
>>  }
>>  #define arch_validate_prot(prot) arch_validate_prot(prot)
> 
> Please don't do things like this.  They're not obviously correct and
> also have no obvious benefit.  You also don't mention why you bothered
> to alter the logical structure of these checks.
> 

For all cases, bool is equal or a little better than int, and they are
equal in our case (2 final outputs are same). So for me, it may belong
to trivial patch, which can be skipped by the normal patch maintainers.

As a 'trivial' patch:

 - For a pure Boolean function, bool return value is more readable than
   int.

 - If one statement can express the same expression, and is as simple as
   the original 'if' statement, one statement is better than 3 original
   statements.

 - In our case:

	if ((prot & PROT_SAO) && !cpu_has_feature(CPU_FTR_SAO))
		return 0;
	return 1;

   equal to:

	return !((prot & PROT_SAO) && !cpu_has_feature(CPU_FTR_SAO));

   equal to:

	return !(prot & PROT_SAO) || !!cpu_has_feature(CPU_FTR_SAO);

   then:

	return (prot & PROT_SAO) == 0 || cpu_has_feature(CPU_FTR_SAO);

Thanks
-- 
Chen Gang (陈刚)

Managing Natural Environments is the Duty of Human Beings.