linux-kernel - RE: [PATCH 3/4] zsmalloc use zs

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 May 2012 16:50:30 -0700 (PDT)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	Minchan Kim <minchan@...nel.org>,
	Konrad Wilk <konrad.wilk@...cle.com>
Cc:	Nitin Gupta <ngupta@...are.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Seth Jennings <sjenning@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: RE: [PATCH 3/4] zsmalloc use zs_handle instead of void *

> From: Minchan Kim [mailto:minchan@...nel.org]
> 
> Okay. Now it works but zcache coupled with zsmalloc tightly.
> User of zsmalloc should never know internal of zs_handle.
> 
> 3)
> 
> - zsmalloc.h
> void *zs_handle_to_ptr(struct zs_handle handle)
> {
> 	return handle.hanle;
> }
> 
> static struct zv_hdr *zv_create(..)
> {
> 	struct zs_handle handle;
> 	..
> 	handle = zs_malloc(pool, size);
> 	..
> 	return zs_handle_to_ptr(handle);
> }
> 
> Why should zsmalloc support such interface?
> It's a zcache problem so it's desriable to solve it in zcache internal.
> And in future, if we can add/remove zs_handle's fields, we can't make
> sure such API.

Hi Minchan --

I'm confused so maybe I am misunderstanding or you can
explain further.  It seems like you are trying to redesign
zsmalloc so that it can be a pure abstraction in a library.
While I understand and value abstractions in software
designs, the primary use now of zsmalloc is in zcache.  If
there are other users that require a different interface
or a more precise abstract API, zsmalloc could then
evolve to meet the needs of multiple users.  But I think
zcache is going to need more access to the internals
of its allocator, not less.  Zsmalloc is currently missing
some important functionality that (I believe) will be
necessary to turn zcache into an enterprise-ready,
always-on kernel feature.  If it evolves to add that
functionality, then it may no longer be able to provide
generic abstract access... in which case generic zsmalloc
may then have zero users in the kernel.

So I'd suggest we hold off on trying to make zsmalloc
"pretty" until we better understand how it will be used
by zcache (and ramster) and, if there are any, any future
users.

That's just my opinion...
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/