linux-kernel - Re: linux-next: Tree for March 10 (crypto & NLATTR)

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: <49B6C8BF.8010105@oracle.com>
Date:	Tue, 10 Mar 2009 13:08:31 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
CC:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	herbert@...dor.apana.org.au, David Miller <davem@...emloft.net>,
	linux-crypto@...r.kernel.org
Subject: Re: linux-next: Tree for March 10 (crypto & NLATTR)

Geert Uytterhoeven wrote:
> On Tue, Mar 10, 2009 at 19:57, Randy Dunlap <randy.dunlap@...cle.com> wrote:
>> Stephen Rothwell wrote:
>>> Changes since 20090306:
>>>
>>>
>>> The driver-core tree gained a build failure due to a conflict with the
>>> crypto tree.  I have applied a patch to the crypto tree for today.
>> I had several (4 of 50) randconfig builds fail with:
>>
>> lib/built-in.o: In function `__nla_reserve_nohdr':
>> (.text+0xd08d): undefined reference to `skb_put'
>> lib/built-in.o: In function `__nla_reserve':
>> (.text+0xd121): undefined reference to `skb_put'
>> lib/built-in.o: In function `nla_append':
>> (.text+0xd493): undefined reference to `skb_put'
>>
>> which happens with CONFIG_NET=n, CONFIG_CRYPTO=y, CONFIG_CRYPTO_ZLIB=[my].
>>
>> CRYPTO_ZLIB selects NLATTR, but obviously the build of nlattr.c fails
>> when CONFIG_NET=n.  Should CRYPTO_ZLIB depend on NET?
>> Please don't say that CRYPTO_ZLIB should select NET.
> 
> Bummer, my fault (commit e9cc8bddaea3944fabfebb968bc88d603239beed,
> netlink: Move netlink attribute parsing support to lib).
> 
> Obviously I was only worried about crypto/zlib.c needing nlattr.c
> without pulling in the whole networking code, not about nlattr.c
> itself needing networking functionality. But still, how could I have
> missed this compile failure?
> 
> Does it sound sane to protect the routines that do call skb_put() by
> #ifdef CONFIG_NET?

I'll have to let David or Herbert answer that.  From my quick look
at the code, I don't see much use for nlattr.c when CONFIG_NET
is not enabled.

-- 
~Randy
--
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/