This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] glibc: Terminate process on invalid netlink response from kernel [BZ #12926]
- From: Hannes Frederic Sowa <hannes at stressinduktion dot org>
- To: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, davem at davemloft dot net
- Cc: Hannes Sowa <hannes at redhat dot com>, netdev at vger dot kernel dot org
- Date: Thu, 05 Nov 2015 15:36:54 +0100
- Subject: Re: [PATCH] glibc: Terminate process on invalid netlink response from kernel [BZ #12926]
- Authentication-results: sourceware.org; auth=none
- References: <562A9391 dot 1040806 at redhat dot com> <1446558492 dot 1880442 dot 427793993 dot 78B20B4F at webmail dot messagingengine dot com> <5638BDE3 dot 2040608 at redhat dot com>
Hello,
On Tue, Nov 3, 2015, at 15:00, Florian Weimer wrote:
> On 11/03/2015 02:48 PM, Hannes Frederic Sowa wrote:
> > Hello,
> >
> > On Fri, Oct 23, 2015, at 21:07, Florian Weimer wrote:
> >> (By the way, we'd also love to have a better kernel interface to fulfill
> >> the needs for getaddrinfo address sorting. The netlink requests we
> >> currently use are much too slow if the host has many addresses
> >> configured.)
> >
> > One solution would be to finish the IPv6 ioctl interface to list
> > addresses. The ioctl interface would need less memory allocations and is
> > a synchronous interface which would make it much more easier for glibc
> > to deal with. No timeouts and retries like with netlink are necessary.
>
> The more fundamental question is whether we actually have to copy all
> the addresses to userspace. In the end, it may be better to hand a list
> of destination addresses to the kernel and have it sort them according
> to some algorithm. But for the algorithm proposed in RFC 6724 section
> 6, this may be not worth the effort because there are so many
> configurable bits.
I would rather not provide a holistic sort function in the kernel for
both IPv4 and IPv6 which would a requirement by glibc, no?
> I still think most of the address sorting is bogus because it appears to
> make guarantees which can break after renumbering.
Yes, of course.
Your patch for glibc looks fine to me, so
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Bye,
Hannes