lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 7 Nov 2022 13:36:25 -0800 From: Nhat Pham <nphamcs@...il.com> To: senozhatsky@...omium.org Cc: hannes@...xchg.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org, minchan@...nel.org, ngupta@...are.org, akpm@...ux-foundation.org, sjenning@...hat.com, ddstreet@...e.org, vitaly.wool@...sulko.com Subject: Re: [PATCH 4/5] zsmalloc: Add ops fields to zs_pool to store evict handlers 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).
Powered by blists - more mailing lists