Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751385AbdIMF7T (ORCPT ); Wed, 13 Sep 2017 01:59:19 -0400 Received: from mx2.suse.de ([195.135.220.15]:44878 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751056AbdIMF7S (ORCPT ); Wed, 13 Sep 2017 01:59:18 -0400 Date: Wed, 13 Sep 2017 07:59:14 +0200 From: Michal Hocko To: YASUAKI ISHIMATSU Cc: linux-mm@kvack.org, LKML , qiuxishi@huawei.com, arbab@linux.vnet.ibm.com, Vlastimil Babka Subject: Re: [PATCH] mm/memory_hotplug: fix wrong casting for __remove_section() Message-ID: <20170913055914.3npcxevhdwghcmdd@dhcp22.suse.cz> References: <51a59ec3-e7ba-2562-1917-036b8181092c@gmail.com> <20170912124952.uraxdt5bgl25zhf7@dhcp22.suse.cz> <587bdecd-2584-21be-94b8-61b427f1b0e8@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <587bdecd-2584-21be-94b8-61b427f1b0e8@gmail.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1014 Lines: 31 On Tue 12-09-17 13:05:39, YASUAKI ISHIMATSU wrote: > Hi Michal, > > Thanks you for reviewing my patch. > > On 09/12/2017 08:49 AM, Michal Hocko wrote: > > On Fri 08-09-17 16:43:04, YASUAKI ISHIMATSU wrote: > >> __remove_section() calls __remove_zone() to shrink zone and pgdat. > >> But due to wrong castings, __remvoe_zone() cannot shrink zone > >> and pgdat correctly if pfn is over 0xffffffff. > >> > >> So the patch fixes the following 3 wrong castings. > >> > >> 1. find_smallest_section_pfn() returns 0 or start_pfn which defined > >> as unsigned long. But the function always returns 32bit value > >> since the function is defined as int. > >> > >> 2. find_biggest_section_pfn() returns 0 or pfn which defined as > >> unsigned long. the function always returns 32bit value > >> since the function is defined as int. > > > > this is indeed wrong. Pfns over would be really broken 15TB. Not that > > unrealistic these days > > Why 15TB? 0xffffffff>>28 -- Michal Hocko SUSE Labs