[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20240710121802.e1445448d94b3f6ea16fdd12@linux-foundation.org>
Date: Wed, 10 Jul 2024 12:18:02 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Hugh Dickins <hughd@...gle.com>
Cc: Usama Arif <usamaarif642@...il.com>, kernel test robot
<oliver.sang@...el.com>, Johannes Weiner <hannes@...xchg.org>,
oe-lkp@...ts.linux.dev, lkp@...el.com, Linux Memory Management List
<linux-mm@...ck.org>, Chengming Zhou <chengming.zhou@...ux.dev>, Yosry
Ahmed <yosryahmed@...gle.com>, Nhat Pham <nphamcs@...il.com>, David
Hildenbrand <david@...hat.com>, "Huang, Ying" <ying.huang@...el.com>,
Matthew Wilcox <willy@...radead.org>, Shakeel Butt
<shakeel.butt@...ux.dev>, Andi Kleen <ak@...ux.intel.com>,
linux-kernel@...r.kernel.org, ltp@...ts.linux.it
Subject: Re: [linux-next:master] [mm] 47325a5c88:
WARNING:at_mm/slub.c:#free_large_kmalloc
On Wed, 10 Jul 2024 11:49:09 -0700 (PDT) Hugh Dickins <hughd@...gle.com> wrote:
> It's a long time since I was active hereabouts, but the bot report
> and your flurry of updates make me think that you should step back,
> slow down, and look more carefully at the precedents here.
>
> IIRC, the main problem is that parts of the swap_info_struct can
> still be in use from before while you're wanting to set up new values.
> Observe how alloc_swap_info() may return a fresh or an old allocation.
> Observe how enable_swap_info() is called after getting swapon_mutex
> late in swapon(), once past all possiblities of error.
>
> I expect that your new zeromap needs to be taking the same care as is
> taken with swap_map and cluster_info: to be safe, follow their example
> in both swapon() and swapoff().
Thanks. I've dropped the series "mm: store zero pages to be swapped
out in a bitmap" from mm-stable. Let's revisit in the next -rc cycle.
Powered by blists - more mailing lists