From: Hugh Dickins <hughd@google.com>
To: Usama Arif <usamaarif642@gmail.com>
Cc: kernel test robot <oliver.sang@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
oe-lkp@lists.linux.dev, lkp@intel.com,
Linux Memory Management List <linux-mm@kvack.org>,
Chengming Zhou <chengming.zhou@linux.dev>,
Yosry Ahmed <yosryahmed@google.com>,
Nhat Pham <nphamcs@gmail.com>,
David Hildenbrand <david@redhat.com>,
"Huang, Ying" <ying.huang@intel.com>,
Hugh Dickins <hughd@google.com>,
Matthew Wilcox <willy@infradead.org>,
Shakeel Butt <shakeel.butt@linux.dev>,
Andi Kleen <ak@linux.intel.com>,
linux-kernel@vger.kernel.org, ltp@lists.linux.it
Subject: Re: [linux-next:master] [mm] 47325a5c88: WARNING:at_mm/slub.c:#free_large_kmalloc
Date: Wed, 10 Jul 2024 11:49:09 -0700 (PDT) [thread overview]
Message-ID: <612af749-0a59-f91d-693a-43d6217ffebb@google.com> (raw)
In-Reply-To: <4bc6400e-6199-4147-9399-4a54c94613fd@gmail.com>
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().
Hugh
next prev parent reply other threads:[~2024-07-10 18:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-10 2:51 kernel test robot
2024-07-10 10:29 ` Usama Arif
2024-07-10 16:46 ` Usama Arif
2024-07-10 18:33 ` Usama Arif
2024-07-10 18:49 ` Hugh Dickins [this message]
2024-07-10 19:02 ` Usama Arif
2024-07-10 19:14 ` Hugh Dickins
2024-07-10 19:18 ` Andrew Morton
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=612af749-0a59-f91d-693a-43d6217ffebb@google.com \
--to=hughd@google.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=chengming.zhou@linux.dev \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=ltp@lists.linux.it \
--cc=nphamcs@gmail.com \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=shakeel.butt@linux.dev \
--cc=usamaarif642@gmail.com \
--cc=willy@infradead.org \
--cc=ying.huang@intel.com \
--cc=yosryahmed@google.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