This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Simplify sendmmsg code



On 09/05/2017 17:28, Florian Weimer wrote:
> On 05/09/2017 08:41 PM, Adhemerval Zanella wrote:
>> I think we can add a sysdeps/posix sendmmsg based on sendmsg so we can
>> safely remove this macro usage on resolv code.  I will work on this
>> after your patch inclusion.
> 
> The use of sendmmsg in the resolv code is problematic.  We need to use two separate sockets with different source ports to improve compatibility anyway.  This might also help firewalls with tearing down state more quickly (single request/response very likely does not bump the UDP timeout, but two requests and two responses might switch into stream mode with a prolonged timeout; maybe that's why we originally hit the Netfilter table overflow in some of the glibc resolver tests).
> 
> I'm not sure how quickly I will get to fixing this (I hope for 2.26), so please do whatever you feel is necessary in the meantime.
> 
> Thanks,
> Florian

So if I understood correctly, the idea is to *remove* sendmmsg on resolv code then?
Because now with __ASSUME_SENDMMSG being used as default for Linux this code will
be used on all architectures.

In any case, my understanding for sendmmsg is it is a GNU extension (similar to
pwritev), so the idea is to have a fallback usable code on sysdeps/{posix,unix}
to we do not need to actually tests its usability in the rest of glibc code.
That's why I think that if the idea is actually get rid of sendmmsg usage in
resolv, we can add a generic implementation for sendmmsg and then remove its
usage on two cleanup patches.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]