Received: by 10.213.65.68 with SMTP id h4csp21365imn; Fri, 6 Apr 2018 14:42:44 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/lx1T7yMol2r3NTweAzJd3mw7zIIPvLgCXKUVMTZmZ2B8+dRpR8vYvTKFUiRUvdTVwUB9H X-Received: by 10.101.83.7 with SMTP id m7mr18801967pgq.1.1523050964896; Fri, 06 Apr 2018 14:42:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523050964; cv=none; d=google.com; s=arc-20160816; b=A/6Ld37SOxhLL0si7FuEe95CfiWA1GUNWZvfeHlstUBlpxQYXXsjD1IQFk1M46T/Lx 56/Qpj/bGALIBD+LVY4BHzCPbllJ+KhzFN93/KWuB5KRXNFsjxDtFI+4lPbYl80PLtZO amaMlrr19Hh11cjjZqyZk76YqoOX/zDYxn+jiNVrCCq4ek1hcxEC5qKvAay1WA4v9UKs 3+uLq5nr9dCTBLu4Tis7MYlEYeBYrp5YXimCnfMRyMdngGqnZx1cXHFCPwYXtmUlpT0n Simm6UaVV8KOv7AbZWct98E67lm0zC5d+P7b26yp0jnrZccFh8UoXEc6noOt95rYLNl3 WGLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:dkim-signature:message-id:date:subject:cc :to:from:arc-authentication-results; bh=pVwLhOlcDENhh/YCxVbINI6eCBpf3+wPB8dh8c3Zpf0=; b=yjDEKBCQw5lXhddUQ1hzAEWRFCjhVE0r6sUQVd3RylYYUSPIxMi6NH4usteeroQbut cHGcHK4LJz+u14R4WrKY78wucJJEffDrt/oEwTWFZ+YydCt9Ju87k7Y/X4FYV+EkubyV TD8zANCeEzPHprr+7eTQm654klhnl+naA8j7OU7tRduHIjokXY/aPlZlQy8FK7RzjctT XG1E9VesQBkADnYUtl1BP/AopTipNxls1EjkckR+ZEMaJfhRwX5gBlXlGIvTQ3G7XylG 6Lt/orBHVODrjDOUD1eM5uL2jAgYlK2CnQeiMvIC66Nyy/QCA4F0MPXw77QkfmRXwkFz dEfA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@agner.ch header.s=dkim header.b=rZhnxGHL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p13-v6si9374495pll.416.2018.04.06.14.42.08; Fri, 06 Apr 2018 14:42:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@agner.ch header.s=dkim header.b=rZhnxGHL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751926AbeDFViU (ORCPT + 99 others); Fri, 6 Apr 2018 17:38:20 -0400 Received: from mail.kmu-office.ch ([178.209.48.109]:42219 "EHLO mail.kmu-office.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751417AbeDFViT (ORCPT ); Fri, 6 Apr 2018 17:38:19 -0400 Received: from trochilidae.lan (unknown [IPv6:2001:1620:c6e::edf]) by mail.kmu-office.ch (Postfix) with ESMTPSA id 63F8C5C1AF6; Fri, 6 Apr 2018 23:37:33 +0200 (CEST) From: Stefan Agner To: akpm@linux-foundation.org, mhocko@suse.com, catalin.marinas@arm.com Cc: torvalds@linux-foundation.org, pasha.tatashin@oracle.com, ard.biesheuvel@linaro.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Stefan Agner Subject: [PATCH] mm/memblock: introduce PHYS_ADDR_MAX Date: Fri, 6 Apr 2018 23:38:09 +0200 Message-Id: <20180406213809.566-1-stefan@agner.ch> X-Mailer: git-send-email 2.17.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agner.ch; s=dkim; t=1523050653; bh=pVwLhOlcDENhh/YCxVbINI6eCBpf3+wPB8dh8c3Zpf0=; h=From:To:Cc:Subject:Date:Message-Id; b=rZhnxGHLpSaCiNUmr+bZVe+6HgneiEpM2b7TlvCmL+cvYjPMyKJ7moknwedxIs/98EvlkSAaJbHdFmpNuYk0D+7hlabMKBB5TeDK9MO/ugmg1gWeLH7c8SphQVODcDA/Qtn7VfJKdzF5ApH+y5xMLwAFBEx1nGROLE/le5AW6/0= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org So far code was using ULLONG_MAX and type casting to obtain a phys_addr_t with all bits set. The typecast is necessary to silence compiler warnings on 32-bit platforms. Use the simpler but still type safe approach "~(phys_addr_t)0" to create a preprocessor define for all bits set. Suggested-by: Linus Torvalds Signed-off-by: Stefan Agner --- Hi, There are about a dozen other instances of (phys_addr_t)ULLONG_MAX accross the tree. Should I address them too? -- Stefan include/linux/kernel.h | 1 + mm/memblock.c | 22 +++++++++++----------- 2 files changed, 12 insertions(+), 11 deletions(-) diff --git a/include/linux/kernel.h b/include/linux/kernel.h index 3fd291503576..1ba9e2d71bc9 100644 --- a/include/linux/kernel.h +++ b/include/linux/kernel.h @@ -29,6 +29,7 @@ #define LLONG_MIN (-LLONG_MAX - 1) #define ULLONG_MAX (~0ULL) #define SIZE_MAX (~(size_t)0) +#define PHYS_ADDR_MAX (~(phys_addr_t)0) #define U8_MAX ((u8)~0U) #define S8_MAX ((s8)(U8_MAX>>1)) diff --git a/mm/memblock.c b/mm/memblock.c index 696829a198ba..957587178b36 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -67,7 +67,7 @@ ulong __init_memblock choose_memblock_flags(void) /* adjust *@size so that (@base + *@size) doesn't overflow, return new size */ static inline phys_addr_t memblock_cap_size(phys_addr_t base, phys_addr_t *size) { - return *size = min(*size, (phys_addr_t)ULLONG_MAX - base); + return *size = min(*size, PHYS_ADDR_MAX - base); } /* @@ -924,7 +924,7 @@ void __init_memblock __next_mem_range(u64 *idx, int nid, ulong flags, r = &type_b->regions[idx_b]; r_start = idx_b ? r[-1].base + r[-1].size : 0; r_end = idx_b < type_b->cnt ? - r->base : (phys_addr_t)ULLONG_MAX; + r->base : PHYS_ADDR_MAX; /* * if idx_b advanced past idx_a, @@ -1040,7 +1040,7 @@ void __init_memblock __next_mem_range_rev(u64 *idx, int nid, ulong flags, r = &type_b->regions[idx_b]; r_start = idx_b ? r[-1].base + r[-1].size : 0; r_end = idx_b < type_b->cnt ? - r->base : (phys_addr_t)ULLONG_MAX; + r->base : PHYS_ADDR_MAX; /* * if idx_b advanced past idx_a, * break out to advance idx_a @@ -1543,13 +1543,13 @@ phys_addr_t __init_memblock memblock_end_of_DRAM(void) static phys_addr_t __init_memblock __find_max_addr(phys_addr_t limit) { - phys_addr_t max_addr = (phys_addr_t)ULLONG_MAX; + phys_addr_t max_addr = PHYS_ADDR_MAX; struct memblock_region *r; /* * translate the memory @limit size into the max address within one of * the memory memblock regions, if the @limit exceeds the total size - * of those regions, max_addr will keep original value ULLONG_MAX + * of those regions, max_addr will keep original value PHYS_ADDR_MAX */ for_each_memblock(memory, r) { if (limit <= r->size) { @@ -1564,7 +1564,7 @@ static phys_addr_t __init_memblock __find_max_addr(phys_addr_t limit) void __init memblock_enforce_memory_limit(phys_addr_t limit) { - phys_addr_t max_addr = (phys_addr_t)ULLONG_MAX; + phys_addr_t max_addr = PHYS_ADDR_MAX; if (!limit) return; @@ -1572,14 +1572,14 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit) max_addr = __find_max_addr(limit); /* @limit exceeds the total size of the memory, do nothing */ - if (max_addr == (phys_addr_t)ULLONG_MAX) + if (max_addr == PHYS_ADDR_MAX) return; /* truncate both memory and reserved regions */ memblock_remove_range(&memblock.memory, max_addr, - (phys_addr_t)ULLONG_MAX); + PHYS_ADDR_MAX); memblock_remove_range(&memblock.reserved, max_addr, - (phys_addr_t)ULLONG_MAX); + PHYS_ADDR_MAX); } void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size) @@ -1607,7 +1607,7 @@ void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size) /* truncate the reserved regions */ memblock_remove_range(&memblock.reserved, 0, base); memblock_remove_range(&memblock.reserved, - base + size, (phys_addr_t)ULLONG_MAX); + base + size, PHYS_ADDR_MAX); } void __init memblock_mem_limit_remove_map(phys_addr_t limit) @@ -1620,7 +1620,7 @@ void __init memblock_mem_limit_remove_map(phys_addr_t limit) max_addr = __find_max_addr(limit); /* @limit exceeds the total size of the memory, do nothing */ - if (max_addr == (phys_addr_t)ULLONG_MAX) + if (max_addr == PHYS_ADDR_MAX) return; memblock_cap_memory_range(0, max_addr); -- 2.17.0