RE: [PATCH v13 19/22] mm: zswap: Per-CPU acomp_ctx resources exist from pool creation to deletion.

["Sridhar, Kanchana P" <kanchana.p.sridhar@intel.com>]

> -----Original Message-----
> From: Yosry Ahmed <yosry.ahmed@linux.dev>
> Sent: Thursday, December 11, 2025 6:47 PM
> To: Sridhar, Kanchana P <kanchana.p.sridhar@intel.com>
> Cc: linux-kernel@vger.kernel.org; linux-mm@kvack.org;
> hannes@cmpxchg.org; nphamcs@gmail.com; chengming.zhou@linux.dev;
> usamaarif642@gmail.com; ryan.roberts@arm.com; 21cnbao@gmail.com;
> ying.huang@linux.alibaba.com; akpm@linux-foundation.org;
> senozhatsky@chromium.org; sj@kernel.org; kasong@tencent.com; linux-
> crypto@vger.kernel.org; herbert@gondor.apana.org.au;
> davem@davemloft.net; clabbe@baylibre.com; ardb@kernel.org;
> ebiggers@google.com; surenb@google.com; Accardi, Kristen C
> <kristen.c.accardi@intel.com>; Gomes, Vinicius <vinicius.gomes@intel.com>;
> Feghali, Wajdi K <wajdi.k.feghali@intel.com>; Gopal, Vinodh
> <vinodh.gopal@intel.com>; Sridhar, Kanchana P
> <kanchana.p.sridhar@intel.com>
> Subject: Re: [PATCH v13 19/22] mm: zswap: Per-CPU acomp_ctx resources
> exist from pool creation to deletion.
> 
> December 11, 2025 at 5:58 PM, "Sridhar, Kanchana P"
> <kanchana.p.sridhar@intel.com
> mailto:kanchana.p.sridhar@intel.com?to=%22Sridhar%2C%20Kanchana%20
> P%22%20%3Ckanchana.p.sridhar%40intel.com%3E > wrote:
> 
> 
> >
> > >
> > > -----Original Message-----
> > >  From: Yosry Ahmed <>
> > >  Sent: Thursday, December 11, 2025 5:06 PM
> > >  To: Sridhar, Kanchana P <>
> > >  Cc:;;
> > >  hannes@cmpxchg.org; mailto:hannes@cmpxchg.org; ;;
> > >  usamaarif642@gmail.com; mailto:usamaarif642@gmail.com; ;;
> > >  ying.huang@linux.alibaba.com; mailto:ying.huang@linux.alibaba.com; ;
> > >  senozhatsky@chromium.org; mailto:senozhatsky@chromium.org; ;;
> linux-
> > >  crypto@vger.kernel.org; mailto:crypto@vger.kernel.org; ;
> > >  davem@davemloft.net; mailto:davem@davemloft.net; ;;
> > >  ebiggers@google.com; mailto:ebiggers@google.com; ; Accardi, Kristen C
> > >  <>; Gomes, Vinicius <>;
> > >  Feghali, Wajdi K <>; Gopal, Vinodh
> > >  <>
> > >  Subject: Re: [PATCH v13 19/22] mm: zswap: Per-CPU acomp_ctx
> resources
> > >  exist from pool creation to deletion.
> > >
> > >  On Fri, Dec 12, 2025 at 12:55:10AM +0000, Sridhar, Kanchana P wrote:
> > >
> > >  > -----Original Message-----
> > >  > From: Yosry Ahmed <>
> > >  > Sent: Thursday, November 13, 2025 12:24 PM
> > >  > To: Sridhar, Kanchana P <>
> > >  > Cc:;;
> > >  >;;
> > >  chengming.zhou@linux.dev; mailto:chengming.zhou@linux.dev;
> > >  >;;;
> > >  >;;
> > >  >;;; linux-
> > >  >;;
> > >  >;;;
> > >  >;; Accardi, Kristen C
> > >  > <>; Gomes, Vinicius
> > >  <>;
> > >  > Feghali, Wajdi K <>; Gopal, Vinodh
> > >  > <>
> > >  > Subject: Re: [PATCH v13 19/22] mm: zswap: Per-CPU acomp_ctx
> > >  resources
> > >  > exist from pool creation to deletion.
> > >  >
> > >  > On Tue, Nov 04, 2025 at 01:12:32AM -0800, Kanchana P Sridhar wrote:
> > >  >
> > >  > The subject can be shortened to:
> > >  >
> > >  > "mm: zswap: Tie per-CPU acomp_ctx lifetime to the pool"
> > >  >
> > >  > > This patch simplifies the zswap_pool's per-CPU acomp_ctx resource
> > >  > > management. Similar to the per-CPU acomp_ctx itself, the per-CPU
> > >  > > acomp_ctx's resources' (acomp, req, buffer) lifetime will also be from
> > >  > > pool creation to pool deletion. These resources will persist through
> CPU
> > >  > > hotplug operations instead of being destroyed/recreated. The
> > >  > > zswap_cpu_comp_dead() teardown callback has been deleted from
> the
> > >  call
> > >  > > to cpuhp_setup_state_multi(CPUHP_MM_ZSWP_POOL_PREPARE). As
> a
> > >  > result, CPU
> > >  > > offline hotplug operations will be no-ops as far as the acomp_ctx
> > >  > > resources are concerned.
> > >  >
> > >  > Currently, per-CPU acomp_ctx are allocated on pool creation and/or
> CPU
> > >  > hotplug, and destroyed on pool destruction or CPU hotunplug. This
> > >  > complicates the lifetime management to save memory while a CPU is
> > >  > offlined, which is not very common.
> > >  >
> > >  > Simplify lifetime management by allocating per-CPU acomp_ctx once
> on
> > >  > pool creation (or CPU hotplug for CPUs onlined later), and keeping them
> > >  > allocated until the pool is destroyed.
> > >  >
> > >  > >
> > >  > > This commit refactors the code from zswap_cpu_comp_dead() into a
> > >  > > new function acomp_ctx_dealloc() that is called to clean up
> acomp_ctx
> > >  > > resources from:
> > >  > >
> > >  > > 1) zswap_cpu_comp_prepare() when an error is encountered,
> > >  > > 2) zswap_pool_create() when an error is encountered, and
> > >  > > 3) from zswap_pool_destroy().
> > >  >
> > >  >
> > >  > Refactor cleanup code from zswap_cpu_comp_dead() into
> > >  > acomp_ctx_dealloc() to be used elsewhere.
> > >  >
> > >  > >
> > >  > > The main benefit of using the CPU hotplug multi state instance
> startup
> > >  > > callback to allocate the acomp_ctx resources is that it prevents the
> > >  > > cores from being offlined until the multi state instance addition call
> > >  > > returns.
> > >  > >
> > >  > > From Documentation/core-api/cpu_hotplug.rst:
> > >  > >
> > >  > > "The node list add/remove operations and the callback invocations
> are
> > >  > > serialized against CPU hotplug operations."
> > >  > >
> > >  > > Furthermore, zswap_[de]compress() cannot contend with
> > >  > > zswap_cpu_comp_prepare() because:
> > >  > >
> > >  > > - During pool creation/deletion, the pool is not in the zswap_pools
> > >  > > list.
> > >  > >
> > >  > > - During CPU hot[un]plug, the CPU is not yet online, as Yosry pointed
> > >  > > out. zswap_cpu_comp_prepare() will be run on a control CPU,
> > >  > > since CPUHP_MM_ZSWP_POOL_PREPARE is in the PREPARE section
> > >  of
> > >  > "enum
> > >  > > cpuhp_state". Thanks Yosry for sharing this observation!
> > >  > >
> > >  > > In both these cases, any recursions into zswap reclaim from
> > >  > > zswap_cpu_comp_prepare() will be handled by the old pool.
> > >  > >
> > >  > > The above two observations enable the following simplifications:
> > >  > >
> > >  > > 1) zswap_cpu_comp_prepare(): CPU cannot be offlined. Reclaim
> cannot
> > >  > use
> > >  > > the pool. Considerations for mutex init/locking and handling
> > >  > > subsequent CPU hotplug online-offline-online:
> > >  > >
> > >  > > Should we lock the mutex of current CPU's acomp_ctx from start to
> > >  > > end? It doesn't seem like this is required. The CPU hotplug
> > >  > > operations acquire a "cpuhp_state_mutex" before proceeding, hence
> > >  > > they are serialized against CPU hotplug operations.
> > >  > >
> > >  > > If the process gets migrated while zswap_cpu_comp_prepare() is
> > >  > > running, it will complete on the new CPU. In case of failures, we
> > >  > > pass the acomp_ctx pointer obtained at the start of
> > >  > > zswap_cpu_comp_prepare() to acomp_ctx_dealloc(), which again, can
> > >  > > only undergo migration. There appear to be no contention scenarios
> > >  > > that might cause inconsistent values of acomp_ctx's members. Hence,
> > >  > > it seems there is no need for mutex_lock(&acomp_ctx->mutex) in
> > >  > > zswap_cpu_comp_prepare().
> > >  > >
> > >  > > Since the pool is not yet on zswap_pools list, we don't need to
> > >  > > initialize the per-CPU acomp_ctx mutex in zswap_pool_create(). This
> > >  > > has been restored to occur in zswap_cpu_comp_prepare().
> > >  > >
> > >  > > zswap_cpu_comp_prepare() checks upfront if acomp_ctx->acomp is
> > >  > > valid. If so, it returns success. This should handle any CPU
> > >  > > hotplug online-offline transitions after pool creation is done.
> > >  > >
> > >  > > 2) CPU offline vis-a-vis zswap ops: Let's suppose the process is
> > >  > > migrated to another CPU before the current CPU is dysfunctional. If
> > >  > > zswap_[de]compress() holds the acomp_ctx->mutex lock of the
> > >  offlined
> > >  > > CPU, that mutex will be released once it completes on the new
> > >  > > CPU. Since there is no teardown callback, there is no possibility of
> > >  > > UAF.
> > >  > >
> > >  > > 3) Pool creation/deletion and process migration to another CPU:
> > >  > >
> > >  > > - During pool creation/deletion, the pool is not in the zswap_pools
> > >  > > list. Hence it cannot contend with zswap ops on that CPU. However,
> > >  > > the process can get migrated.
> > >  > >
> > >  > > Pool creation --> zswap_cpu_comp_prepare()
> > >  > > --> process migrated:
> > >  > > * CPU offline: no-op.
> > >  > > * zswap_cpu_comp_prepare() continues
> > >  > > to run on the new CPU to finish
> > >  > > allocating acomp_ctx resources for
> > >  > > the offlined CPU.
> > >  > >
> > >  > > Pool deletion --> acomp_ctx_dealloc()
> > >  > > --> process migrated:
> > >  > > * CPU offline: no-op.
> > >  > > * acomp_ctx_dealloc() continues
> > >  > > to run on the new CPU to finish
> > >  > > de-allocating acomp_ctx resources
> > >  > > for the offlined CPU.
> > >  > >
> > >  > > 4) Pool deletion vis-a-vis CPU onlining:
> > >  > > The call to cpuhp_state_remove_instance() cannot race with
> > >  > > zswap_cpu_comp_prepare() because of hotplug synchronization.
> > >  > >
> > >  > > This patch deletes
> acomp_ctx_get_cpu_lock()/acomp_ctx_put_unlock().
> > >  > > Instead, zswap_[de]compress() directly call
> > >  > > mutex_[un]lock(&acomp_ctx->mutex).
> > >  >
> > >  > I am not sure why all of this is needed. We should just describe why
> > >  > it's safe to drop holding the mutex while initializing per-CPU
> > >  > acomp_ctx:
> > >  >
> > >  > It is no longer possible for CPU hotplug to race against allocation or
> > >  > usage of per-CPU acomp_ctx, as they are only allocated once before the
> > >  > pool can be used, and remain allocated as long as the pool is used.
> > >  > Hence, stop holding the lock during acomp_ctx initialization, and drop
> > >  > acomp_ctx_get_cpu_lock()//acomp_ctx_put_unlock().
> > >
> > >  Hi Yosry,
> > >
> > >  Thanks for these comments. IIRC, there was quite a bit of technical
> > >  discussion analyzing various what-ifs, that we were able to answer
> > >  adequately. The above is a nice summary of the outcome, however,
> > >  I think it would help the next time this topic is re-visited to have a log
> > >  of the "why" and how races/UAF scenarios are being considered and
> > >  addressed by the solution. Does this sound Ok?
> > >
> > >  How about using the summarized version in the commit log and linking to
> > >  the thread with the discussion?
> > >
> > Seems like capturing just enough detail of the threads involving the
> > discussions, in this commit log would be valuable. As against reading long
> > email threads with indentations, as the sole resource to provide context?
> >
> 
> If you feel strongly about it then sure, but try to keep it as concise as possible,
> thanks.

Sure, will do, thanks!