linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Markus Gothe <markus.gothe@genexis.eu>
To: David Hildenbrand <david@redhat.com>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	Zi Yan <ziy@nvidia.com>
Subject: Re: get_pageblock_bitmap() sometimes returns a NULL pointer which needs to be properly handled
Date: Mon, 6 May 2024 10:01:16 +0000	[thread overview]
Message-ID: <f9665d73-d8d5-4af0-8368-0ea08c33e6f5@genexis.eu> (raw)
In-Reply-To: <96439935-ce2a-4714-be5d-cdeb8ea0eb41@redhat.com>

Hi David,
it is from a vendor SDK for an emedded system using Linux 5.4.55.

BR,
Markus

On 06/05/2024 11.54, David Hildenbrand wrote:
> On 06.05.24 11:39, Baolin Wang wrote:
>> Ccing David.
>>
>> On 2024/5/3 00:02, Markus Gothe wrote:
>>> Hi,
>>> under some rare occasion I run into the following crash:
>>>
>>> [   41.417606] pstate: 80400005 (Nzcv daif +PAN -UAO)
>>> [   41.422406] pc : set_pfnblock_flags_mask+0x50/0x94
>>> [   41.427193] lr : compaction_alloc+0x220/0x804
>>> [   41.431544] sp : ffffffc01104bb10
>>> [   41.434852] x29: ffffffc01104bb10 x28: ffffffc010e5b500
>>> [   41.440165] x27: 0000000000098000 x26: ffffffc010e5b500
>>> [   41.445477] x25: 0000000000000066 x24: 0000000000090800
>>> [   41.450789] x23: 0000000000000200 x22: 0000000000084000
>>> [   41.456093] x21: ffffffc010e82000 x20: ffffffc010b88000
>>> [   41.461396] x19: ffffffc01104bd70 x18: 0000000000000000
>>> [   41.466700] x17: f1f24e35df34dda4 x16: 6b3f63a0e1157268
>>> [   41.472004] x15: 4b3990ec2568ada0 x14: 757ebc126939cb5f
>>> [   41.477308] x13: 9df9488aba179ccb x12: 0000000000000000
>>> [   41.482612] x11: 0000000000000000 x10: ffffffc010c5fc30
>>> [   41.487916] x9 : ffffff801eea7c00 x8 : 000000001bf00000
>>> [   41.493219] x7 : 0000000000000000 x6 : 000000000000003f
>>> [   41.498525] x5 : 0000000000000108 x4 : 1000000000000000
>>> [   41.503835] x3 : 0000000000000021 x2 : 000000000000003c
>>> [   41.509139] x1 : 0000000000000001 x0 : 0000000000000003
>>> [   41.514443] Call trace:
>>> [   41.516887]  set_pfnblock_flags_mask+0x50/0x94
>>> [   41.521330]  migrate_pages+0x90/0x7f0
>>> [   41.524992]  compact_zone+0x854/0x9f0
>>> [   41.528647]  kcompactd_do_work+0x168/0x230
>>> [   41.532734]  kcompactd+0x58/0x140
>>> [   41.536043]  kthread+0x120/0x124
>>> [   41.539263]  ret_from_fork+0x10/0x24
>>> [   41.542835] Code: d346fc43 4b0000c2 8b030ce5 9ac22084 (f86378e0)
>>> [   41.548925] ---[ end trace 731400a587304db3 ]---
>>>
>>>
>>> I've pin-pointed it down to pageblock_flags pointer being 
>>> initialized to NULL under certain conditions. I don't know why this 
>>> happens.
>>> Maybe it is some obscure race condition which only shows up on my 
>>> system.
>>
>> Is there memory hotplug in your test? It seems to be caused by the race
>> between memory hotplug and PFN walkers (such as compaction), which is
>> already a known issue.
>
> I think I've never seen races with access to pageblocks but only with 
> access to the memmap.
>
> Further, I'd not expect races during migrate_pages()? We're holding a 
> reference do all folios when calling migrate_pages(). So memory 
> offlining+removal would not be able to succeed until we drop these 
> references.
>
> But, could it be that we failing during compaction_alloc() [lr : 
> compaction_alloc+0x220/0x804] and have an issue during 
> set_pfnblock_flags_mask() on a page that sits on the isolated 
> freelist? Similarly, memory hotunplug should not be able to mess up here.
>
> [again, racing with memory hotunplug is unlikely]
>
> On which kernel did we start seeing this issue?
>

  reply	other threads:[~2024-05-06 10:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-02 16:02 Markus Gothe
2024-05-06  9:39 ` Baolin Wang
2024-05-06  9:51   ` Markus Gothe
2024-05-06  9:54   ` David Hildenbrand
2024-05-06 10:01     ` Markus Gothe [this message]
2024-05-06 10:45       ` David Hildenbrand
2024-05-06 10:42     ` Oscar Salvador

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=f9665d73-d8d5-4af0-8368-0ea08c33e6f5@genexis.eu \
    --to=markus.gothe@genexis.eu \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=ziy@nvidia.com \
    /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