Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Nhat Pham <nphamcs@gmail.com>
To:     senozhatsky@chromium.org
Cc:     hannes@cmpxchg.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, minchan@kernel.org,
        ngupta@vflare.org, akpm@linux-foundation.org, sjenning@redhat.com,
        ddstreet@ieee.org, vitaly.wool@konsulko.com
Subject: Re: [PATCH 4/5] zsmalloc: Add ops fields to zs_pool to store evict handlers
Date:   Mon,  7 Nov 2022 13:36:25 -0800
Message-Id: <20221107213625.939660-1-nphamcs@gmail.com>
In-Reply-To: <Y2Htmak6+7b+6pBv@google.com>
References: <Y2Htmak6+7b+6pBv@google.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

Essentially, the zpool constructor allows us to set things up with a null
struct zpool, zpool_ops, or zpool_ops->evict, which we have to handle.  A
similar null-handling pattern can be observed in zbud (mm/zbud.c) and z3fold
(mm/z3fold.c) - see zbud_zpool_evict and zbud_zpool_create for e.g.

In particular:

1. pool->zpool_ops is the ops (containing the evict handler zpool_ops->evict)
passed into the zpool constructor (zs_zpool_create)

2. pool->ops/zs_zpool_ops (struct zs_ops) is a struct wrapping zs_zpool_evict,
which itself is a wrapper for the zpool evict handler (pool->zpool_ops->evict).
zs_zpool_evict also handles the case where zpool or zpool_ops is null, or
zpool_ops->evict is not defined (i.e return -ENOENT).

FWIW, I do think this is quite convoluted. In the long run, we might want to
simplify this design, but for this patch series I think it is wise to err on
the safe side and follow the other two allocators' design for consistency.

That said, while staring at the code again, I found a bug - in the case
pool->zpool_ops is null, pool->ops is undefined garbage. The v3 patch will fix
that to follow zbud's pattern (pool->ops = NULL in this case).