From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932235AbcIMJ03 (ORCPT ); Tue, 13 Sep 2016 05:26:29 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:39919 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757725AbcIMJ00 (ORCPT ); Tue, 13 Sep 2016 05:26:26 -0400 X-IBM-Helo: d03dlp03.boulder.ibm.com X-IBM-MailFrom: rui.teng@linux.vnet.ibm.com From: Rui Teng To: linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: Andrew Morton , Michal Hocko , Naoya Horiguchi , Chen Gang , "Kirill A . Shutemov" , Vlastimil Babka , "Aneesh Kumar K . V" , hejianet@linux.vnet.ibm.com, Rui Teng Subject: [RFC] mm: Change the data type of huge page size from unsigned long to u64 Date: Tue, 13 Sep 2016 17:26:05 +0800 X-Mailer: git-send-email 2.7.4 X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16091309-0024-0000-0000-000014888270 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00005753; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000185; SDB=6.00757171; UDB=6.00359000; IPR=6.00530531; BA=6.00004712; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00012657; XFM=3.00000011; UTC=2016-09-13 09:26:24 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16091309-0025-0000-0000-000044681097 Message-Id: <1473758765-13673-1-git-send-email-rui.teng@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-09-13_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609130139 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The huge page size could be 16G(0x400000000) on ppc64 architecture, and it will cause an overflow on unsigned long data type(0xFFFFFFFF). For example, huge_page_size() will return 0, if the PAGE_SIZE is 65536 and h->order is 18, which is the result on ppc64 with 16G huge page enabled. I think it needs to change the data type from unsigned long to u64. But it will cause a lot of functions and data structures changed. Any comments and suggestions? Thanks! Signed-off-by: Rui Teng --- include/linux/hugetlb.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index c26d463..efbe5cf 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -374,9 +374,9 @@ static inline struct hstate *hstate_vma(struct vm_area_struct *vma) return hstate_file(vma->vm_file); } -static inline unsigned long huge_page_size(struct hstate *h) +static inline u64 huge_page_size(struct hstate *h) { - return (unsigned long)PAGE_SIZE << h->order; + return (u64)PAGE_SIZE << h->order; } extern unsigned long vma_kernel_pagesize(struct vm_area_struct *vma); -- 2.7.4