[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250929151744.2922386-1-joshua.hahnjy@gmail.com>
Date: Mon, 29 Sep 2025 08:17:27 -0700
From: Joshua Hahn <joshua.hahnjy@...il.com>
To: kernel test robot <oliver.sang@...el.com>
Cc: oe-lkp@...ts.linux.dev,
lkp@...el.com,
Chris Mason <clm@...com>,
Johannes Weiner <hannes@...xchg.org>,
linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>,
Kiryl Shutsemau <kirill@...temov.name>,
"Brendan Jackman" <jackmanb@...gle.com>,
Michal Hocko <mhocko@...e.com>,
"Suren Baghdasaryan" <surenb@...gle.com>,
Vlastimil Babka <vbabka@...e.cz>,
Zi Yan <ziy@...dia.com>,
linux-kernel@...r.kernel.org,
kernel-team@...a.com
Subject: Re: [PATCH v2 4/4] mm/page_alloc: Batch page freeing in free_frozen_page_commit
On Sun, 28 Sep 2025 13:17:37 +0800 kernel test robot <oliver.sang@...el.com> wrote:
Hello Kernel Test Robot,
> Hello,
>
> kernel test robot noticed "WARNING:bad_unlock_balance_detected" on:
>
> commit: 7e86100bfb0d65a17f3228a9af4c2a49ac38f057 ("[PATCH v2 4/4] mm/page_alloc: Batch page freeing in free_frozen_page_commit")
> url: https://github.com/intel-lab-lkp/linux/commits/Joshua-Hahn/mm-page_alloc-vmstat-Simplify-refresh_cpu_vm_stats-change-detection/20250925-044532
> patch link: https://lore.kernel.org/all/20250924204409.1706524-5-joshua.hahnjy@gmail.com/
> patch subject: [PATCH v2 4/4] mm/page_alloc: Batch page freeing in free_frozen_page_commit
>
> in testcase: trinity
> version:
> with following parameters:
>
> runtime: 300s
> group: group-03
> nr_groups: 5
>
> config: x86_64-randconfig-161-20250927
> compiler: gcc-14
> test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
>
> (please refer to attached dmesg/kmsg for entire log/backtrace)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <oliver.sang@...el.com>
> | Closes: https://lore.kernel.org/oe-lkp/202509281204.3086f707-lkp@intel.com
>
>
> [ 414.880298][ T7549] WARNING: bad unlock balance detected!
> [ 414.881071][ T7549] 6.17.0-rc6-00147-g7e86100bfb0d #1 Not tainted
> [ 414.881924][ T7549] -------------------------------------
> [ 414.882695][ T7549] date/7549 is trying to release lock (&pcp->lock) at:
> [ 414.883649][ T7549] free_frozen_page_commit+0x425/0x9d0
> [ 414.884764][ T7549] but there are no more locks to release!
> [ 414.885539][ T7549]
> [ 414.885539][ T7549] other info that might help us debug this:
> [ 414.886704][ T7549] 2 locks held by date/7549:
> [ 414.887353][ T7549] #0: ffff888104f29940 (&mm->mmap_lock){++++}-{4:4}, at: exit_mmap (include/linux/seqlock.h:431 include/linux/mmap_lock.h:88 include/linux/mmap_lock.h:398 mm/mmap.c:1288)
> [ 414.888591][ T7549] #1: ffff8883ae40e858 (&pcp->lock){+.+.}-{3:3}, at: free_frozen_page_commit+0x46a/0x9d0
So based on this, it seems like I must have overlooked a pretty important
consideration here. When I unlock the pcp, it allows both the zone and pcp
lock to be picked up by another task (pcp lock less likely), but it also
means that this process can be migrated to a different CPU, where it will
be trying to unlock & acquire a completely different pcp.
For me the most simple solution looks to be migrate_disable() and
migrate_enable() in the function to ensure that this task is bound to the
CPU it originally started runing on.
I'm not sure how this will affect performance, but I think in terms of
desired behavior it does seem like this is the correct way to do it.
Joshua
Powered by blists - more mailing lists