The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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

      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