From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0469BC27C75 for ; Wed, 12 Jun 2024 07:01:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 877016B015D; Wed, 12 Jun 2024 03:01:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8262D6B015E; Wed, 12 Jun 2024 03:01:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C6696B015F; Wed, 12 Jun 2024 03:01:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 4DA6A6B015D for ; Wed, 12 Jun 2024 03:01:50 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C812F41447 for ; Wed, 12 Jun 2024 07:01:49 +0000 (UTC) X-FDA: 82221341538.22.0A8DA53 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by imf18.hostedemail.com (Postfix) with ESMTP id C99E81C0010 for ; Wed, 12 Jun 2024 07:01:47 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PsOXT53M; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.44 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718175707; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=mZWb2w/0OFEI08wSIySsA4c0/SlbB29gBCLByPB2Zh8=; b=VzQyvfO1+mwiJwSJC1ijcWKbZYOe6e9gKuIZ2P9oSccN/wIvdRFN0mP3QjRwY4WsMBQf97 AFYWqsoKXLyaZQW/TN9n+pLnp1K0GD1rn6NUKCuKb1jUqCIeprGAtKfM9U8PTOPEuJ6+cc ovO3CKVgvCTW86Br//lefXMuPY0G9vU= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PsOXT53M; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.44 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718175707; a=rsa-sha256; cv=none; b=6R7TYDFDJYFh6WZwMBgBXpiqGTEs1GIYTQ9atNj1DY/9kUWYipdKsQKTZnIYK74LdwsSla ja+BpGLqcK+ilyodWjwz1dmL8jBu/MUkpgz3dKkpVBz1/OWThIjtBv01B9nBb25VSVt2zr ROiOWrJzc0kHBjJ2/JbVwuwAeapmob8= Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-57c68682d1aso4775870a12.3 for ; Wed, 12 Jun 2024 00:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718175706; x=1718780506; darn=kvack.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=mZWb2w/0OFEI08wSIySsA4c0/SlbB29gBCLByPB2Zh8=; b=PsOXT53Md5HRZQ0v/DEghVWKRQjvep+d/NYUEJp/hXM1s4F82AV6RvyvKeEUIFm+ZP 9t4mxBeWQypVWtSMSOmLAcpOdfWaJibv6941qdQcuDhnFON9GhTspOKaTewcJVrjerYK 9cT7QZJu81bf6uF3vZEiz7JTJ6gxuYJRiJGTC9ODoHVcdMu6gFomxsi0d0dX1p5piZ/j KYhK2zANq6beal0oLJjEvGS83Xzp0xG6EV0z7wSDSeWYxZNbzrB/azj01KgV+S6YqY4E Xw1mjDsv3V3arawRKsPlc/d0DpbjJVL7XGN3aOn3bOYUck2ei+4bd/8x8LgVHAy/rv7G gi3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718175706; x=1718780506; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=mZWb2w/0OFEI08wSIySsA4c0/SlbB29gBCLByPB2Zh8=; b=LyGnfwK0huviVm0Djl5ozj8IQ10+HUEOShOZoBPPpi7/GJiYM8sLSR3sUIulq4OdHI VAxf94mMX9ldNEAAsWgdia20R9M+btsZzTuVGPYiUBW6MOJukjqBioaxcb9fcUjZgVXm hrnpL6fIDggg5urA4aq689KYHog7l7uVxN7v92N4RXCPuPUTKDfw45ac6EKRRhWzrbgR /a/GbozB05Etu7lBw4sVFsKZhdhrjphjxDWy3eD/UTY1eh/Fk4GJVzBVBh4j09cg65nP 8n+2L6BZMIBVcx8pmDIk1YYoqv467TuzQTjn3VeD2Il3P698Et2YSlOJU/bbTDacXa8p Webw== X-Forwarded-Encrypted: i=1; AJvYcCXMKAV51SDHSkWMl14n1Fw/kChTw1ceJKX0heYzUw4fN1LDUv+FAkv68FhGdsanwmz01bVfka4RUvLffhbVGhH3zUs= X-Gm-Message-State: AOJu0YzNjt9nAV4MlIQevNY8QV3d+rXVLodxw3w1TmihiyOUapG+a0zy ycw0YlLw32tE9JjyhKq11pZqPhpp5Xasu1DGXmb8I5BMwd2cIGWU X-Google-Smtp-Source: AGHT+IEv6+Oc78NKNWzu+X/qVCIvMEWWddDcJq63Bl4+Z+rURzKK9VufbNW/KtVVgGXgkIaV6IO60w== X-Received: by 2002:a05:6402:3086:b0:57c:677a:a941 with SMTP id 4fb4d7f45d1cf-57caaac68e0mr382554a12.40.1718175705832; Wed, 12 Jun 2024 00:01:45 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-57aae229712sm10543736a12.81.2024.06.12.00.01.45 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 12 Jun 2024 00:01:45 -0700 (PDT) Date: Wed, 12 Jun 2024 07:01:44 +0000 From: Wei Yang To: David Hildenbrand Cc: Wei Yang , Oscar Salvador , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton Subject: Re: [PATCH v1 2/2] mm/highmem: make nr_free_highpages() return "unsigned long" Message-ID: <20240612070144.q6rpbq2hkwtielav@master> Reply-To: Wei Yang References: <20240607083711.62833-1-david@redhat.com> <20240607083711.62833-3-david@redhat.com> <99073d55-5b18-4ed2-b860-8c09e056f585@redhat.com> <20240611005636.g6525rkqpos43yds@master> <04b3dda2-c6a8-4f26-90b8-75fe7580d63e@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04b3dda2-c6a8-4f26-90b8-75fe7580d63e@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) X-Rspamd-Queue-Id: C99E81C0010 X-Rspamd-Server: rspam10 X-Rspam-User: X-Stat-Signature: 8sx41hxee4zwamkbobcrd8kqtry8dgcz X-HE-Tag: 1718175707-838285 X-HE-Meta: U2FsdGVkX19M8Zv97Ofuz6oYL9x44PBPEECEPCUGuGh8uYz/+4yaCkqytfU+CdWlm8VhlCV+Q6ENIgx/j7F4tpQA3JKWg/QzEQ1lntIHrD1r83kloV7ojoAL+wftXQlPx4UoeNwWmM8GNNJbGO6tDwzUqo8eswy0VCM8b8pCz8HT3TuHcWvw0bBXTYsbQJwlpZQIC6jEH1pGVbXbZQHMFkVs2gKoC5ZPSdbxsutChpanwMdtJmenhTz2GNke6oug8g+ZteEGc9imyoJZYhAzj+EJkNqrAvNnm2xLPzWj0z8MxMUZ4GjMTVG7RKazEJ6nFOD0PLEY6WHJzc21+bu+hdS23FIbhOUxSj3KP6iYWbzlMUSSrEe/dHVwcLPeekw2JGWo+AF9B0IwzFX3/nvxtOJRCd7Fm+fLGrbJb6RnwfFfTq7teRfacfBkRGHRWqroxp37JFeWXhMLdIgSPDQ0DR0g+6Yl746hC7ELWmyT00nUhUG0GHEn230HrnUsBhf3hgGs5bBP6uVCIaLn1so3tvT0qHGaBXbvqvDvITpDqfpI4FHnPLwb7Bz/vkl4PY3RwENKJ1f/WfltG8VogxyV0frIuJqGwpwHb4AFoY4P3UVJy+aJn9E/WAoJsSX7E0hvstUQ+A5Cd/f/5jb6UD9pjpmpEim26Vj8vkg/CrSoFXgZ9UWcFHq4wXv7R0ulUCbwxXZKdhpJo9qz70dCXb+g48bRzmPwEfAWYhst/pWYHovTnh4WSXAPM1VSzC06Mj++IVjmrWnxwyREqEmOUYNY6DqG5AlFk15qPbrSkHxCwFdicTCzULMy7mKPDgVwLY5znvGxlleQleIEa7hCeoOzvkl4E8KX+OE2CCOvy5jfPfTQo+xVszhxRTqusMMalPdYAbI1ONDcR8oQp/6op6Oia3b++LHoKZGAwl50nWG7OyryvfXfT0NjCzjQLpXphBd0G5xgzpeZjxtyn/UCsd0 /KRBF0EC ddrIsfFD2fL5CDBXRXT1GfQuF+rWC0aUwaVh1DUeJCYvvPsNLCEKM0FOEFUG4yYnLLUt80ZoHl5bFO5Ev3AtN6GkjLlivri7jm6aSJQx83hRxUp9vz891P9popSgSz1JXtm3h1typlm7wCBRrD5O433eXyXg0DMgdwg0jD5dC7Q1bPIEEmlyZapGyTPpKaTIzdU+tpZeDsrQy45RXEiR8b0IhHG7VVPvFtL8qGpX1nZNV0KOZNbKX1Hj75eCpN+Xa3wDLlIoMWTTe/+okiJO5ZygS1or9W/9D4Q0MOvB98njNN6MfwKP6A7rxmU2tOxMIdH47WdHiEuqAPlKNoweCw0AqkU3EqxBIh/ffxif9BM2lO3HxjXTC9FFZ8QHzLR50YmINKvKq0cscrO6kGX+LmsoBa+KKTEwSyf3YdpQymbuN1DW5jjCRg5EphCgkqZvOLXWTxv+NJGNjeb82lA0hEMYbqVPl0adpStw8NY+9xJydc5Y+E8jmVAv/s6X+k+P2N7chrN4EfOfpZrHPSAJVhIJlYG6fp/SzjcPZSlGz+X4fgejCKY+7OiGJb/yAnKCauRaof6/Tbcci7o3aE3+Zc2W8VwIpk9KhWIMvgKblcU/l+yhXd+LUIer69RN2o2O6jym4mZOk8w8lzQkUHxUXsRAt+tRFTLUemRNB X-Bogosity: Ham, tests=bogofilter, spamicity=0.000009, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jun 11, 2024 at 11:20:00AM +0200, David Hildenbrand wrote: >On 11.06.24 02:56, Wei Yang wrote: >> On Mon, Jun 10, 2024 at 10:22:49AM +0200, David Hildenbrand wrote: >> > On 10.06.24 05:40, Oscar Salvador wrote: >> > > On Fri, Jun 07, 2024 at 10:37:11AM +0200, David Hildenbrand wrote: >> > > > It looks rather weird that totalhigh_pages() returns an >> > > > "unsigned long" but nr_free_highpages() returns an "unsigned int". >> > > > >> > > > Let's return an "unsigned long" from nr_free_highpages() to be >> > > > consistent. >> > > > >> > > > While at it, use a plain "0" instead of a "0UL" in the !CONFIG_HIGHMEM >> > > > totalhigh_pages() implementation, to make these look alike as well. >> > > > >> > > > Signed-off-by: David Hildenbrand >> > > ... >> > > > -static inline unsigned int nr_free_highpages(void) { return 0; } >> > > > -static inline unsigned long totalhigh_pages(void) { return 0UL; } >> > > > +static inline unsigned long nr_free_highpages(void) { return 0; } >> > > > +static inline unsigned long totalhigh_pages(void) { return 0; } >> > > >> > > Although I doubt it has any consequences, I would just leave them both with UL, >> > > so the return type is consistent with what we are returning. >> > >> > These suffixes are only required when using constants that would not fit >> > into the native (int) type, or converting from that native (int) type to >> > something else automatically by the compiler would mess things up (for example, >> > undesired sign extension). For 0 that is certainly impossible :) >> > >> > >> > That's also the reason why in include/linux we now have: >> > >> > t14s: ~/git/linux/include/linux $ git grep "return 0UL;" >> > skbuff.h: return 0UL; >> > uaccess.h:static inline unsigned long user_access_save(void) { return 0UL; } >> > t14s: ~/git/linux/include/linux $ git grep "0UL;" >> > bitmap.h: *dst = ~0UL; >> > dax.h: return ~0UL; >> > mtd/map.h: r.x[i] = ~0UL; >> > netfilter.h: return ((ul1[0] ^ ul2[0]) | (ul1[1] ^ ul2[1])) == 0UL; >> > skbuff.h: return 0UL; >> > uaccess.h:static inline unsigned long user_access_save(void) { return 0UL; } >> > >> > >> > ... compared to a long list if "unsigned long" functions that simply "return 0;" >> > >> >> Seems this is the current status. >> >> Then my question is do we have a guide line for this? Or 0 is the special >> case? Sounds positive value has no sign extension problem. If we need to >> return 1, we suppose to use 1 or 1UL? I found myself confused. >> >> I grepped "return 1" and do find some cases without UL: >> >> backing-dev.h: wb_stat_error() return 1 for unsigned long. >> pgtable.h: pte_batch_hint() return 1 for unsigned int. >> >> So the guide line is for positive value, it is not necessary to use UL? > >I think when returning simple values (0/1/-1), we really don't need these >suffices at all. The standard says "The type of an integer constant is the >first of the corresponding list in which its value can be represented.". I >thought it would always use an "int", but that is not the case. > >So, if we use "-1", the compiler will use an "int", and sign extension to >"unsigned" long will do the right thing. > >Simple test: > >-1 results in: 0xffffffffffffffff >-1U results in: 0xffffffff >-1UL results in: 0xffffffffffffffff >0xffffffff results in: 0xffffffff >0xffffffffU results in: 0xffffffff >0xffffffffUL results in: 0xffffffff >~0xffffffff results in: 0x0 >~0xffffffffU results in: 0x0 >~0xffffffffUL results in: 0xffffffff00000000 >0xffffffffffffffff results in: 0xffffffffffffffff >0xffffffffffffffffU results in: 0xffffffffffffffff I expect this to be 0xffffffff. Why this extend it to a UL? >0xffffffffffffffffUL results in: 0xffffffffffffffff > > >I thought that "0xffffffff" could be a problem (sign-extending to >0xffffffffffffffff), but that does not seem to be the case -- likely using >"unsigned int" as type. Also, I'm surprised that 0xffffffffffffffffU works as >expected, I would have thought the "U" would make the compiler complain about >the value not fitting into an unsigned int. > > >When only returning values, the compiler usually does the right thing. Only >when performing operations on the constant (see ~ example above), we might >have to use the suffixes, depending on the intended outcome. > Looks the guide line is * no need to put suffix on return value * add suffix when performing operations, like ~, << >-- >Cheers, > >David / dhildenb -- Wei Yang Help you, Help me