From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Li Zhe <lizhe.67@bytedance.com>
Cc: akpm@linux-foundation.org, apopple@nvidia.com, arnd@arndb.de,
bp@alien8.de, dave.hansen@linux.intel.com, kees@kernel.org,
linux-arch@vger.kernel.org, linux-hardening@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
mingo@redhat.com, rppt@kernel.org, tglx@kernel.org,
x86@kernel.org
Subject: Re: [PATCH v5 2/8] mm: factor zone-device page init helpers out of __init_zone_device_page
Date: Mon, 6 Jul 2026 15:47:43 +0200 [thread overview]
Message-ID: <374a0a2a-444c-412b-8ab8-414dff6a2ca9@kernel.org> (raw)
In-Reply-To: <20260706115035.49813-1-lizhe.67@bytedance.com>
On 7/6/26 13:50, Li Zhe wrote:
> On Mon, Jul 6, 2026 at 11:13:45AM +0200, david@kernel.org wrote:
>
>>> +static inline bool pagemap_resets_refcount(const struct dev_pagemap *pgmap)
>>> +{
>>> + /*
>>> + * MEMORY_DEVICE_GENERIC pages regain a refcount of 1 in the free
>>> + * path. The remaining ZONE_DEVICE types start from 0 here and raise
>>> + * the count again when the allocator or driver hands the page out.
>>> + */
>>> + switch (pgmap->type) {
>>> + case MEMORY_DEVICE_FS_DAX:
>>> + case MEMORY_DEVICE_PRIVATE:
>>> + case MEMORY_DEVICE_COHERENT:
>>> + case MEMORY_DEVICE_PCI_P2PDMA:
>>> + return false;
>>> + case MEMORY_DEVICE_GENERIC:
>>> + return true;
>>> + default:
>>> + WARN_ONCE(1, "Unknown memory type!");
>>> + return true;
>>
>> Wouldn't the compiler warn if we would define a new type but forgot to update it
>> here? We're using an enum, and I thought the compiler would bail out in that case.
>>
>> Or are we scared of some other garbage ending up in there?
>>
>> Apart from that LGTM.
>
> Thanks.
>
> I will drop the default case in v6 so a newly added enum memory_type
> value is easier to catch during build review.
>
> I will move the WARN_ONCE() after the switch so we still keep a
> runtime guard in case some invalid value ever shows up there.
If the compiler complains, we won't need the WARN_ONCE().
--
Cheers,
David
next prev parent reply other threads:[~2026-07-06 13:47 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 9:05 [PATCH v5 0/8] mm: optimize zone-device memmap initialization Li Zhe
2026-07-01 9:05 ` [PATCH v5 1/8] mm: fix stale ZONE_DEVICE refcount comment Li Zhe
2026-07-06 9:11 ` David Hildenbrand (Arm)
2026-07-07 2:28 ` Alistair Popple
2026-07-01 9:05 ` [PATCH v5 2/8] mm: factor zone-device page init helpers out of __init_zone_device_page Li Zhe
2026-07-06 9:13 ` David Hildenbrand (Arm)
2026-07-06 11:50 ` Li Zhe
2026-07-06 13:47 ` David Hildenbrand (Arm) [this message]
2026-07-07 3:25 ` Li Zhe
2026-07-01 9:05 ` [PATCH v5 3/8] mm: add a set_page_section_from_pfn() helper Li Zhe
2026-07-06 9:15 ` David Hildenbrand (Arm)
2026-07-06 11:52 ` Li Zhe
2026-07-06 13:48 ` David Hildenbrand (Arm)
2026-07-07 3:26 ` Li Zhe
2026-07-01 9:05 ` [PATCH v5 4/8] mm: add a template-based fast path for zone-device page init Li Zhe
2026-07-03 14:06 ` Mike Rapoport
2026-07-06 7:45 ` Li Zhe
2026-07-07 3:06 ` Alistair Popple
2026-07-07 6:36 ` Li Zhe
2026-07-07 3:02 ` Alistair Popple
2026-07-07 6:33 ` Li Zhe
2026-07-01 9:05 ` [PATCH v5 5/8] mm: extend the template fast path to zone-device compound tails Li Zhe
2026-07-07 3:09 ` Alistair Popple
2026-07-07 6:38 ` Li Zhe
2026-07-01 9:05 ` [PATCH v5 6/8] string: introduce memcpy_nt() helpers Li Zhe
2026-07-02 2:16 ` Borislav Petkov
2026-07-02 7:36 ` Li Zhe
2026-07-06 9:18 ` David Hildenbrand (Arm)
2026-07-06 11:53 ` Li Zhe
2026-07-06 13:49 ` David Hildenbrand (Arm)
2026-07-07 3:28 ` Li Zhe
2026-07-01 9:05 ` [PATCH v5 7/8] x86/string: extend memcpy_flushcache() fixed-size fastpaths Li Zhe
2026-07-02 2:23 ` Borislav Petkov
2026-07-02 7:37 ` Li Zhe
2026-07-03 19:56 ` Borislav Petkov
2026-07-06 7:43 ` Li Zhe
2026-07-06 17:19 ` Borislav Petkov
2026-07-07 11:34 ` Li Zhe
2026-07-01 9:05 ` [PATCH v5 8/8] mm: use memcpy_nt() in zone-device template copies Li Zhe
2026-07-01 23:28 ` [PATCH v5 0/8] mm: optimize zone-device memmap initialization Andrew Morton
2026-07-02 2:24 ` Borislav Petkov
2026-07-02 7:39 ` Li Zhe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=374a0a2a-444c-412b-8ab8-414dff6a2ca9@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=kees@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizhe.67@bytedance.com \
--cc=mingo@redhat.com \
--cc=rppt@kernel.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.