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

[Randy Dunlap]

Geert Uytterhoeven wrote:
> On Tue, Mar 10, 2009 at 19:57, Randy Dunlap <randy.dunlap@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/