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 095C9C27C53 for ; Wed, 12 Jun 2024 07:34:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7F6B06B0187; Wed, 12 Jun 2024 03:34:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 77F136B0188; Wed, 12 Jun 2024 03:34:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F9726B0189; Wed, 12 Jun 2024 03:34:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 3E8766B0187 for ; Wed, 12 Jun 2024 03:34:40 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id CFF241C0C47 for ; Wed, 12 Jun 2024 07:34:39 +0000 (UTC) X-FDA: 82221424278.17.C9A6336 Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by imf27.hostedemail.com (Postfix) with ESMTP id B8BA240016 for ; Wed, 12 Jun 2024 07:34:37 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CDb6QEV+; spf=pass (imf27.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718177677; a=rsa-sha256; cv=none; b=wp7HrAlfPTYjJ8PAfwgE1K5WUu5MePfmGnomaWd0pnA/DUU30Kcz8kw40ujhQe+EUFVT1V XSNd45VH6qQyzVjTecdwnc5dowDsoNj95cIZnjqRefeVxRMakM/1X72gNDsrPvvx+GBnfd vpSEtcD310yI1I1CDYCEjlVTpwE4XAc= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CDb6QEV+; spf=pass (imf27.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718177677; 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=8o77M9qAN+pRgJWJYRJ+nSK3wcPE6vxMUhsaBsoX0kU=; b=O8sn6+FZvBXdAfleY8uhJnAhI5BvWzgDWHlF0C2aAvwb9l84JS38UOeQ0ncxS1huQSQxUT /166ru+h4HVx2fC8MUQjP0O6pNwB5Ba8Lzv1/69RygYvRs80sU1I72cy/KpVQWqnq7zobO FdytonDxSQK8cETI50XcEHy0Vb8AIWE= Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-57a1fe6392eso9606533a12.0 for ; Wed, 12 Jun 2024 00:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718177676; x=1718782476; 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=8o77M9qAN+pRgJWJYRJ+nSK3wcPE6vxMUhsaBsoX0kU=; b=CDb6QEV+Kw54tCP4LOMxjGgyazpCDWkWlqz8P9HwqZrnsM/O7W4JWxFxCJX8rKFfWm ERpztM54KMXaMSS8s3KZG7hrTmv0FK0qP41F48nG7PQ1/HAL0jNkDpohp5UlyhzNheUX Zhoi3K1M3UuszT+Yq3phg+9Uy2WHI5Hbe39EfspOguNJ/o1r7nc9nE9orN/3S/uML9Yc Idf4KwePyGTefqD4BHq2PcxzvsYljBHgMedELhfH7TNX2wdOZIE3v+2y8Ta9Kr/toOKO V0WeV0+ZQiGTc6eIhPz+k/XLMew6hpmmFRt1/gSSTZm2uldQKUSzzF2gE+1aD2o6Nsge 6ueg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718177676; x=1718782476; 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=8o77M9qAN+pRgJWJYRJ+nSK3wcPE6vxMUhsaBsoX0kU=; b=LDSdvHrZovmMma9u9HF+aUkiaDX547mSwB+zMyfeXpLGzhFr1M4GI2QV9YcxtFxw2/ BXGBg8B4c1bIWLEGXSrtocuQgbmaemZSDzk0xAR2Mwm1BevraNdT29059u2ozGxGs5ri gUXCAf5hAFc39eQD+a1HzAyIBi5OLU0qNVYYY1EGIih3j1k0J73cXhpMjHtcel37V/tu wbPyvgujcpoQTrIR7xaENO60wVYgLLV2RmeNISSKHSc+zlEcbg0ZGvptE4JZSMrQg+rs qqaLU2MQJGeSAeXOIOzID0dVtH1CUbhxHIAPNzBcSACmfMDS+hNFwLvS9/AD5FuKcRmj KzVw== X-Forwarded-Encrypted: i=1; AJvYcCUM2OtWoSErQI3xU4Cbk05VyRVDB0RJakwZtkW12kMhKRhzYzHY5s1if/eF4bPqPx0aAHhVuwWA9f9dW89rOKfiAa0= X-Gm-Message-State: AOJu0YyQ1I29mTLpGombOD8JQpclzaFftC83HKorNZa2UlZJl+JCoDgA pGw6r1GyJNibHjbd/+P3pc/MNfDSkejC+c+U1MnwwG+hGmVoNcEc X-Google-Smtp-Source: AGHT+IEjfLXx+nSEe/8KSqR2eK19VmxG5zwhz5cEWknfBmK0RrzQ6CxrwsRbpjmHvKlaPAABxzIu2g== X-Received: by 2002:a50:9f86:0:b0:57c:5f2b:b5a with SMTP id 4fb4d7f45d1cf-57ca9749915mr630736a12.2.1718177676095; Wed, 12 Jun 2024 00:34:36 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-57c8f6095e9sm3099184a12.24.2024.06.12.00.34.35 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 12 Jun 2024 00:34:35 -0700 (PDT) Date: Wed, 12 Jun 2024 07:34:35 +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: <20240612073435.52fch2aut5lxeyhf@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> <20240612070144.q6rpbq2hkwtielav@master> <2d0df7ca-2720-4a0c-95c5-9b665a567e5f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2d0df7ca-2720-4a0c-95c5-9b665a567e5f@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) X-Rspamd-Queue-Id: B8BA240016 X-Rspam-User: X-Rspamd-Server: rspam12 X-Stat-Signature: s651nt8xnzzoa4h7rtqo3u4hkx6yx3jq X-HE-Tag: 1718177677-862027 X-HE-Meta: U2FsdGVkX1/29PpH/BC4tHy/gEbAUPysAd7VZwfr3ZLFw0YpMqmmPT7TCdr8JL76E/i1d0RxKQ7YroHrF/KQMnwFaXqoCgmT1vb7PJ4LarW4xlp8mA1HW3QHOUp2mB0uwZ3WHBOEr5MK9PZMxNsT6FLmeuNUJ5Ni1BnOs7qV8qXadMek1h3/qgq2xE5w4ShSdxQ+XblmuLz3FimF9AR9KP7JObdsRB2pNwgtCB1D/JHaMlvHlGYSMwZB3k0kdj8ImOiZ4QhxIOr4+cM86a39OmIlGcsLpI/vP6OzUYQNyDFnUqyNvAdDq/l0BDj4qPlwkXTp9YAhNjSKF81zUo6iC1mdMW9XhkQQLc2sAI+GDzxoVPg/L7AJRLp7V/5jadOmHBCjIU/5iNdQlqTGDkHkjTUvD7TXAk0ckAnaJCFVFyfpOu4xmpCWu34Nk5m3QsH0IeBZeen1+SWCYXVdErD1OdKGlVbQ083IlDKuEQ2TZPcTHQIoC6P56v3gS3Mxc3OVaXol7d47f6Y3L+LAeXueIfKOpqbL138RIyVf1lsc4pYpLzpXXhgTqG4uftdtlvkaN+5eBZuFaAeZ4SQGm4zCaCy9dNmRuvKacTmWnklDFrXl7uWSlwYXPhcP1709hEEgktrjM8abpN6qVGIE90I7AyrBrQOUu8opJSn4wERjVklfywEmuRnudYbEz7Ga58YsP4ATemTiPRieLKuxwTF+F9zEbkjY1wv56WLyZ5WJ9WYBUlXP39eO+qlClLuiVhR5cXN1SFy4qxSWrsPk3Ik5iKbr8lwnsNK6xuBaXbg9LLMRVWp/V1ZO6Ld1vJB5826/LLsemsgHwTp3H6XLHljVomLY+V4fK0fdczJ8vej3Ny5VpfSMh4r3A39ae4sNKa3/gSIpn8mKJriUHDhWzjiQ1Xhik3Oad9ePTB/xaW7PEalcBPEd6Eoqcjz3RsGt7g2TfpKg865/KOE3tr+1UgT 6+yWBKBx lGocA7h6I5O5OM7Zefg+rgUIAOALDFg1rc4TDUihF1OiO+sWLlB6Jcdl9FRO36xo5t5gdwmGn1XvXKwYW8RCMNHSRGRYXJ77k/oghYWimMDmW0CBcJTc4yt5owfj2SyzXkU8bWvF7LZR2T654O3M4q78JFPbtvjNcvwGTcLflvFosihZD83+MNIIlYwEiMcqqYGDJYNAphgZK2ZEuNqLeDF5UlUj+SsX3kbAtGG+gXxmHe24eDZUHOf06vT6icQXq0lxnaws4VgXseAGuc3+iAnWfPMsB/Zf83Ql93ombulph0jV28/ovHkvL/VYZ8kTkiVmOpFaERFwfgqq0kx0m05nmB0t/Jl4y4FY60mPIm0czJoXqqWkRuiUTYfGc8PVYynDVVYumDoStBqurB/Y6FehM9a3pCtHKVvZmyb4U3K6EZ+HDTg8XncjX8e7yDx1a20G+HUIt7V6+YmLyi0Mxy2R7pM87RxLo0Q5PEszrs06Ehp0a5gdEiachxr+/PTLYAAJ1YZ9Nlb3h57oHswii82nKR+CNdbTtW6sD+XEFnC8/OO/Yde+pW3+pcQ1NoVzJG4bGVCzhFnhNyuYU+3BjX5abDVYrhFUgJH/qyVqqX3qNW85OfgjpB9J285TWNm+PI98sWAyDL0+YtojEEMyycw31Z4Moge06mpAG1wqgKMAGAlyDsfKPWtpD9ZD9XEul2TM87FepI6KJjIk69Z2UqPIXwfPrLrluGeylo9V3+lU2br67GFHXMWAuENuqn90wJVIr9+QE1bfOH56PH78FcSa0pl9QqYX0Hb/AfdL684MTL+H3YXtER7FIblwNgjNTuopZoMMLupL599BQel2cTzOYOw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.005350, 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 Wed, Jun 12, 2024 at 09:22:25AM +0200, David Hildenbrand wrote: >On 12.06.24 09:01, Wei Yang wrote: >> 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? > >Apparently, the "U" only restricts the set of types to "unsigned ones". > >https://en.cppreference.com/w/cpp/language/integer_literal > >So the compiler will use the first "unsigned" type that can hold that value. > Interesting, thanks for the reference. Reviewed-by: Wei Yang >-- >Cheers, > >David / dhildenb -- Wei Yang Help you, Help me