From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1D1A630FF36 for ; Tue, 10 Mar 2026 08:23:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773131015; cv=none; b=NpvgKk6x/H10stKKBeUtkoKat8q3PqgdaBkwMxtMsS4uGcipDVBdQ/MAiXyXVVwGwHKNZBBo2Gl0WGD0teE7OWYxsL3AU2EwrwtU8wrzUyhYWTU76DywoB80psX7c61NaJkZ5Tq56gemBi6ZnOvf+iR9z98IxaWBpD/sNfEg9XM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773131015; c=relaxed/simple; bh=b5fmJwbJfrTikfaiWZiuL6mCps+R4DvXaUUiA4iSru8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=OorobT/1dOe9rEl9g2dnKPYBFNsHCh+ExXtHCSYIUOo9jqv96lVujdiBoDHA8BKt9oGwLpUC42QyKIwUoYh+myuJYdf/Oft/QC4PV+IyH/PXIbiHwfDjKdeC5wppmyJ14j2MOKqlZjBttabZb78W/h5NvZ/5r+5srEUl/rSoQog= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 317B616A3; Tue, 10 Mar 2026 01:23:27 -0700 (PDT) Received: from [10.164.19.59] (unknown [10.164.19.59]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 860FA3F7BD; Tue, 10 Mar 2026 01:23:24 -0700 (PDT) Message-ID: <04a7465b-ee69-479f-aaa4-ccdf3ae16805@arm.com> Date: Tue, 10 Mar 2026 13:53:21 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/9] mm/rmap: make nr_pages signed in try_to_unmap_one To: "David Hildenbrand (Arm)" , "Lorenzo Stoakes (Oracle)" Cc: akpm@linux-foundation.org, axelrasmussen@google.com, yuanchu@google.com, hughd@google.com, chrisl@kernel.org, kasong@tencent.com, weixugc@google.com, Liam.Howlett@oracle.com, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, riel@surriel.com, harry.yoo@oracle.com, jannh@google.com, pfalcato@suse.de, baolin.wang@linux.alibaba.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, bhe@redhat.com, baohua@kernel.org, youngjun.park@lge.com, ziy@nvidia.com, kas@kernel.org, willy@infradead.org, yuzhao@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, ryan.roberts@arm.com, anshuman.khandual@arm.com References: <20260310073013.4069309-1-dev.jain@arm.com> <20260310073013.4069309-2-dev.jain@arm.com> <21801fb7-0f42-4ad3-8b85-2ac6013b8aa5@lucifer.local> <31f93292-3de6-475c-b7fe-82ef41a3a7de@kernel.org> Content-Language: en-US From: Dev Jain In-Reply-To: <31f93292-3de6-475c-b7fe-82ef41a3a7de@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 10/03/26 1:36 pm, David Hildenbrand (Arm) wrote: > On 3/10/26 08:56, Lorenzo Stoakes (Oracle) wrote: >> On Tue, Mar 10, 2026 at 01:00:05PM +0530, Dev Jain wrote: >>> Currently, nr_pages is defined as unsigned long. We use nr_pages to >>> manipulate mm rss counters for lazyfree folios as follows: >>> >>> add_mm_counter(mm, MM_ANONPAGES, -nr_pages); >>> >>> Suppose nr_pages = 3. -nr_pages underflows and becomes ULONG_MAX - 2. Then, >>> since add_mm_counter() uses this -nr_pages as a long, ULONG_MAX - 2 does >>> not fit into the positive range of long, and is converted to -3. Eventually >>> all of this works out, but for keeping things simple, declare nr_pages as >>> a signed variable. >>> >>> Signed-off-by: Dev Jain >>> --- >>> mm/rmap.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/mm/rmap.c b/mm/rmap.c >>> index 6398d7eef393f..087c9f5b884fe 100644 >>> --- a/mm/rmap.c >>> +++ b/mm/rmap.c >>> @@ -1979,9 +1979,10 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma, >>> struct page *subpage; >>> struct mmu_notifier_range range; >>> enum ttu_flags flags = (enum ttu_flags)(long)arg; >>> - unsigned long nr_pages = 1, end_addr; >>> + unsigned long end_addr; >>> unsigned long pfn; >>> unsigned long hsz = 0; >>> + long nr_pages = 1; >> >> This is a non-issue that makes the code confusing, so let's not? >> >> The convention throughout the kernel is nr_pages generally is unsigned because >> you can't have negative nr_pages. > > Indeed. Documented in: > > commit fa17bcd5f65ed702df001579cca8c885fa6bf3e7 > Author: Aristeu Rozanski > Date: Tue Aug 26 11:37:21 2025 -0400 > > mm: make folio page count functions return unsigned > > As raised by Andrew [1], a folio/compound page never spans a negative > number of pages. Consequently, let's use "unsigned long" instead of > "long" consistently for folio_nr_pages(), folio_large_nr_pages() and > compound_nr(). > > Using "unsigned long" as return value is fine, because even > "(long)-folio_nr_pages()" will keep on working as expected. Using > "unsigned int" instead would actually break these use cases. > > This patch takes the first step changing these to return unsigned long > (and making drm_gem_get_pages() use the new types instead of replacing > min()). > > In the future, we might want to make more callers of these functions to > consistently use "unsigned long". So when I was playing around with the code, I noticed that passing unsigned int nr_pages to add_mm_counter(-nr_pages) messes up things. Then I noticed we have an unsigned long here, which prevents that. This is quite non-trivial information for me, especially when I searched around the codebase and found this is the only place where we pass a negative unsigned long. But thanks for pointing out this commit. If it is a well-known fact that (long)-folio_nr_pages() will work correctly, then we can drop this patch. > > >