linux-kernel - Re: linux-next: Tree for Apr 19 (zcache)

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]

Message-ID: <20120420163745.GB31062@phenom.dumpdata.com>
Date:	Fri, 20 Apr 2012 12:37:46 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Seth Jennings <sjenning@...ux.vnet.ibm.com>
Cc:	Dan Magenheimer <dan.magenheimer@...cle.com>,
	Nitin Gupta <nitingupta910@...il.com>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Randy Dunlap <rdunlap@...otime.net>,
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: linux-next: Tree for Apr 19 (zcache)

On Thu, Apr 19, 2012 at 11:36:26PM -0500, Seth Jennings wrote:
> On 04/19/2012 05:36 PM, Dan Magenheimer wrote:
> >> From: Randy Dunlap [mailto:rdunlap@...otime.net]
> >> Sent: Thursday, April 19, 2012 4:30 PM
> >> To: Stephen Rothwell
> >> Cc: linux-next@...r.kernel.org; LKML; Dan Magenheimer
> >> Subject: Re: linux-next: Tree for Apr 19 (zcache)
> >>
> >> On 04/18/2012 11:46 PM, Stephen Rothwell wrote:
> >>
> >>> Hi all,
> >>>
> >>> Changes since 20120418:
> >>
> >>
> >> on x86_64:
> >>
> >> drivers/built-in.o: In function `zv_free':
> >> zcache-main.c:(.text+0x5e1c9): undefined reference to `zs_map_object'
> >> zcache-main.c:(.text+0x5e238): undefined reference to `zs_unmap_object'
> >> zcache-main.c:(.text+0x5e29a): undefined reference to `zs_free'
> >> drivers/built-in.o: In function `zv_create':
> >> zcache-main.c:(.text+0x5e6b3): undefined reference to `zs_malloc'
> >> zcache-main.c:(.text+0x5e6f0): undefined reference to `zs_map_object'
> >> zcache-main.c:(.text+0x5e72c): undefined reference to `zs_unmap_object'
> >> drivers/built-in.o: In function `zcache_comp_init':
> >> zcache-main.c:(.text+0x5e831): undefined reference to `crypto_has_alg'
> >> zcache-main.c:(.text+0x5e8a5): undefined reference to `crypto_has_alg'
> >> drivers/built-in.o: In function `zcache_cpu_notifier':
> >> zcache-main.c:(.text+0x5e94f): undefined reference to `crypto_alloc_base'
> >> zcache-main.c:(.text+0x5e9f2): undefined reference to `crypto_destroy_tfm'
> >> drivers/built-in.o: In function `zv_decompress':
> >> zcache-main.c:(.text+0x5ee40): undefined reference to `zs_map_object'
> >> zcache-main.c:(.text+0x5ef06): undefined reference to `zs_unmap_object'
> >> drivers/built-in.o: In function `zcache_pampd_create':
> >> zcache-main.c:(.text+0x5f614): undefined reference to `zs_get_total_size_bytes'
> >> make[1]: *** [.tmp_vmlinux1] Error 1
> 
> The problem is that zsmalloc is being built as a module and zcache is
> builtin.  It seems that because CRYPTO=m, kbuild is forcing zsmalloc
> to be built, just not forcing it to be builtin.
> 
> The zcache Kconfig has:
> 	bool "Dynamic compression of swap pages and clean pagecache pages"
> 	depends on (CLEANCACHE || FRONTSWAP) && CRYPTO && X86
> 	select ZSMALLOC
> 	select CRYPTO_LZO
> 
> Seems to be a nuance of kbuild I didn't know before.  If a
> "selected by" (sub)condition is met, if any of the conditionals are
> built as modules, then the entry can be built as a module.
> 
> For example, if zsmalloc is selected by:
> ...(CLEANCACHE [=y] || FRONTSWAP [=n]) && CRYPTO [=m] && X86 [=y]
> then it can be built as a module or builtin.
> 
> If zsmalloc is selected by:
> ...(CLEANCACHE [=y] || FRONTSWAP [=n]) && CRYPTO [=y] && X86 [=y]
> then it must be builtin.
> 
> One fix is this:
> 
> diff --git a/drivers/staging/zcache/Kconfig b/drivers/staging/zcache/Kconfig
> index 3ed2c8f..7048e01 100644
> --- a/drivers/staging/zcache/Kconfig
> +++ b/drivers/staging/zcache/Kconfig
> @@ -2,7 +2,7 @@ config ZCACHE
>         bool "Dynamic compression of swap pages and clean pagecache pages"
>         # X86 dependency is because zsmalloc uses non-portable pte/tlb
>         # functions
> -       depends on (CLEANCACHE || FRONTSWAP) && CRYPTO && X86
> +       depends on (CLEANCACHE || FRONTSWAP) && CRYPTO=y && X86
>         select ZSMALLOC
>         select CRYPTO_LZO
>         default n
> 
> I think this is the best way since ZCACHE is a bool and CRYPTO is the only
> one of the dependencies that is a tristate.  This forces both ZSMALLOC and
> CRYPTO_LZO to be builtin if ZCACHE is selected.
> 
> Any other suggestions?

Could you do:

default y if (CRYPTO=y || ZSMALLOC=m)
default m if (CRYPTO=m || ZSMALLOC=y)

?
> 
> Thanks,
> Seth
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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/