All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
To: Helge Deller <deller@gmx.de>
Cc: "Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Linux Kernel Development" <linux-kernel@vger.kernel.org>,
	"Linux Memory Management List" <linux-mm@kvack.org>,
	linux-parisc <linux-parisc@vger.kernel.org>
Subject: Re: 6.16-pre-rc1: BUG: Bad page state in process swapper on parisc
Date: Wed, 27 Aug 2025 23:31:02 +0200	[thread overview]
Message-ID: <1756327287@msgid.manchmal.in-ulm.de> (raw)
In-Reply-To: <5a004aef-9df1-4126-b167-1aae27d4240d@gmx.de>

Sorry for being somewhat late to the party ...

Helge Deller wrote a few weeks ago ...

> I'm facing a kernel crash on the 32-bit parisc platform with git head.
> 
> git bisecting leads to this patch which triggers the crash:
> commit ee62ce7a1d90 ("page_pool: Track DMA-mapped pages and unmap them when destroying the pool")
> 
> Syslog:...
> [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 131072
> [    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
> [    0.000000] stackdepot: allocating hash table via alloc_large_system_hash
> [    0.000000] stackdepot hash table entries: 32768 (order: 6, 262144 bytes, linear)
> ..
> [    0.000000] MEMBLOCK configuration: (I added this output during debugging:)
> [    0.000000]  memory size = 0x20000000 reserved size = 0x01f0ed2a
> [    0.000000]  memory.cnt  = 0x1
> [    0.000000]  memory[0x0]     [0x00000000-0x1fffffff], 0x20000000 bytes flags: 0x0
> [    0.000000]  reserved.cnt  = 0xa
> [    0.000000]  reserved[0x0]   [0x00000000-0x0008a0b0], 0x0008a0b1 bytes flags: 0x0
> [    0.000000]  reserved[0x1]   [0x0008a0c0-0x0008a130], 0x00000071 bytes flags: 0x0
> [    0.000000]  reserved[0x2]   [0x0008a140-0x0008a143], 0x00000004 bytes flags: 0x0
> [    0.000000]  reserved[0x3]   [0x0008a150-0x0008a153], 0x00000004 bytes flags: 0x0
> [    0.000000]  reserved[0x4]   [0x0008a160-0x0008a2d3], 0x00000174 bytes flags: 0x0
> [    0.000000]  reserved[0x5]   [0x0008a2e0-0x0008a5e3], 0x00000304 bytes flags: 0x0
> [    0.000000]  reserved[0x6]   [0x0008a5f0-0x0008a6b3], 0x000000c4 bytes flags: 0x0
> [    0.000000]  reserved[0x7]   [0x0008a6c0-0x0008acc3], 0x00000604 bytes flags: 0x0
> [    0.000000]  reserved[0x8]   [0x0008acd0-0x000f6d8f], 0x0006c0c0 bytes flags: 0x0
> [    0.000000]  reserved[0x9]   [0x00100000-0x01f17fff], 0x01e18000 bytes flags: 0x0
> [    0.000000] BUG: Bad page state in process swapper  pfn:000f7
> [    0.000000] page: refcount:0 mapcount:0 mapping:00000000 index:0x0 pfn:0xf7
> [    0.000000] flags: 0x0(zone=0)
> [    0.000000] raw: 00000000 118022c0 118022c0 00000000 00000000 00000000 ffffffff 00000000
> [    0.000000] raw: 00000000
> [    0.000000] page dumped because: page_pool leak
> [    0.000000] Modules linked in:
> [    0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.15.0-rc1-32bit+ #2730 NONE
> [    0.000000] Hardware name: 9000/778/B160L
> [    0.000000] Backtrace:
> [    0.000000]  [<1041d1f4>] show_stack+0x34/0x48
> [    0.000000]  [<10412dd8>] dump_stack_lvl+0x80/0xc8
> [    0.000000]  [<10412e3c>] dump_stack+0x1c/0x2c
> [    0.000000]  [<106ece88>] bad_page+0x14c/0x17c
> [    0.000000]  [<10406c50>] free_page_is_bad.part.0+0xd4/0xec
> [    0.000000]  [<106ed180>] free_page_is_bad+0x80/0x88
> [    0.000000]  [<106ef05c>] __free_pages_ok+0x374/0x508
> [    0.000000]  [<1011d34c>] __free_pages_core+0x1f0/0x218
> [    0.000000]  [<1011a2f0>] memblock_free_pages+0x68/0x94
> [    0.000000]  [<10120324>] memblock_free_all+0x26c/0x310
> [    0.000000]  [<1011a4d8>] mm_core_init+0x18c/0x208
> [    0.000000]  [<10100e88>] start_kernel+0x4ec/0x7a0
> [    0.000000]  [<101054d0>] start_parisc+0xb4/0xc4

The same occured here but due to time constraints and hardware issues I
couldn't dig into this earlier.

Bisecting in the 6.15.y stable series led to commit c30ae60f41f9 which
was cherry-picked from ee62ce7a1d90 ("page_pool: Track DMA-mapped pages
and unmap them when destroying the pool").

The problem still exists in 6.17-rc2.

| HP-UX model name: 9000/785/C3600
if that matters.

    Christoph


  reply	other threads:[~2025-08-27 21:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-03 17:31 6.16-pre-rc1: BUG: Bad page state in process swapper on parisc Helge Deller
2025-08-27 21:31 ` Christoph Biedl [this message]
2025-09-11 22:12   ` boot failure because of inaccurate page_pool_page_is_pp() on 32-bit kernels Helge Deller
2025-09-12  7:57     ` David Hildenbrand
2025-09-12 14:04       ` Helge Deller

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=1756327287@msgid.manchmal.in-ulm.de \
    --to=linux-kernel.bfrz@manchmal.in-ulm.de \
    --cc=deller@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=toke@redhat.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 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.