From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Alistair Popple <apopple@nvidia.com>
Cc: Zenghui Yu <zenghui.yu@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org, jgg@ziepe.ca,
leon@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
ljs@kernel.org, liam@infradead.org, vbabka@kernel.org,
rppt@kernel.org, surenb@google.com, mhocko@suse.com
Subject: Re: "alloc_tag was not set" when running mm/ksft_hmm.sh
Date: Tue, 12 May 2026 09:51:05 +0200 [thread overview]
Message-ID: <8ef6e92d-4cb3-444e-857e-fdbf88c035ea@kernel.org> (raw)
In-Reply-To: <agLZ_BlwTuSZrORF@nvdebian.thelocal>
On 5/12/26 09:46, Alistair Popple wrote:
> On 2026-05-12 at 16:47 +1000, "David Hildenbrand (Arm)" <david@kernel.org> wrote...
>> On 5/12/26 03:28, Alistair Popple wrote:
>>> On 2026-05-12 at 02:38 +1000, Zenghui Yu <zenghui.yu@linux.dev> wrote...
>>>
>>> Thanks. I have reproduced it now that my fingers are skinnier.
>>>
>>>
>>> Well you know what they say about assumptions :) Although in this case
>>> __folio_freeze_and_split_unmapped() isn't called on the backing page anyway
>>> (it's called to split the ZONE_DEVICE page, not the page simulating device
>>> memory).
>>
>> Now my brain hurts :)
>
> I have never liked this bit of the HMM selftests. It has always made my brain
> hurt.
>
>>> The problem is we're not splitting the tag associated with the backing
>>> page for the simulated memory.
>>>
>>> I came up with the below fix last night, but I suspect it will quite reasonably
>>> get NACKED on the basis of the symbol export so was looking at other solutions.
>>
>> I think there are other problems ...
>>
>>>
>>> The simulated memory should just be used like a bare physical address range. So
>>> there really is no reason for the backing page simulating device memory to be
>>> allocated as a higher order folio. Using the struct page to store some metadata
>>> for the simulated device is convenient though to avoid creating a test-specific
>>> data structure for this. So I am looking at going back to allocating the
>>> simulated backing memory as always order-0 pages in the test which is what it
>>> was prior to the introduction of large device pages, but that was causing a
>>> crash I'm yet to debug.
>>>
>>
>> ... such as doing a folio_page(folio_alloc()), followed by a __free_pages().
>>
>> Why are we even allocating folios here and manually splitting them?
>>
>> Looking at dmirror_devmem_folio_split(), aren't we using folios here for
>> something that ... is not a folio?
>>
>> Likely we really shouldn't be using folios here ... :)
>
> Exactly my point, just more succinct :)
>
> I just need to make it work without doing that.
Ok, great. You could also allocate a larger buddy page and just split it
manually through split_page.
split_page will even do the pgalloc_tag_split :)
--
Cheers,
David
prev parent reply other threads:[~2026-05-12 7:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-06 15:42 "alloc_tag was not set" when running mm/ksft_hmm.sh Zenghui Yu
2026-05-08 11:53 ` David Hildenbrand (Arm)
2026-05-08 16:35 ` Alistair Popple
2026-05-11 12:19 ` Zenghui Yu
2026-05-11 12:47 ` David Hildenbrand (Arm)
2026-05-11 16:38 ` Zenghui Yu
2026-05-12 1:05 ` Zenghui Yu
2026-05-12 6:40 ` Alistair Popple
2026-05-12 1:28 ` Alistair Popple
2026-05-12 6:47 ` David Hildenbrand (Arm)
2026-05-12 7:46 ` Alistair Popple
2026-05-12 7:51 ` David Hildenbrand (Arm) [this message]
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=8ef6e92d-4cb3-444e-857e-fdbf88c035ea@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=jgg@ziepe.ca \
--cc=leon@kernel.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=yuzenghui@huawei.com \
--cc=zenghui.yu@linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox