netdev - Re: [PATCH v2] if_bridge: fix conflict with glibc

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] [day] [month] [year] [list]

Message-Id: <20141210.204453.2032479274891251801.davem@davemloft.net>
Date:	Wed, 10 Dec 2014 20:44:53 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	stephen@...workplumber.org
Cc:	gregory.0xf0@...il.com, f.fainelli@...il.com,
	xiyou.wangcong@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH v2] if_bridge: fix conflict with glibc

From: Stephen Hemminger <stephen@...workplumber.org>
Date: Wed, 10 Dec 2014 15:57:45 -0800

> On Wed, 10 Dec 2014 13:34:17 -0500 (EST)
> David Miller <davem@...emloft.net> wrote:
> 
>> No, we really want to incluse the linux/in6.h header, as that's where all
>> the special GLIBC CPP checks are, such as:
>> 
>> #if __UAPI_DEF_IN6_ADDR_ALT
>> 
>> Please research how we have resolved the conflict between GLIBC and the
>> kernel's exported headers.  We really need to use linux/in6.h for all of
>> this to work.
>> 
>> I understand that it is upsetting that iproute2 stopped building for you,
>> but I'd like to kindly ask that you look more deeply into this and think
>> more longer term, rather than having a knee jerk reaction and looking for
>> quick fixes.
> 
> I don't have the time to understand the intricacies of glibc headers.
> The problem is that Gcc warns about duplicate definitions in headers;
> this is a useful warning and not something that I want to disable.
> Hacks with #undef seem to be heading the wrong way.

GLIBC and the kernel have unconditionally defined various types in
their copies of in.h, and the only way to resolve this moving forward
is to have some communication between the two so we can know who is
in fact in charge of instantianting the type.

The new defines, such as __UAPI_DEF_IN6_ADDR_ALT, are that new
mechanism.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html