From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33488 invoked by alias); 9 May 2017 20:58:57 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 33455 invoked by uid 89); 9 May 2017 20:58:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-qk0-f180.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0oXZyfkA+oTXCPZlUqT1rJKToWohzWRVVTuFfAzHKCE=; b=KhyLRNjIx+YPkBznMkW2qmpFzPl2XBs07yinqAmdUIox7TlSxmCK060Dzmk/S9BJID +Lsno4evGExfMcA3+ZYXdZR8bwA5nhyHwjcCQ3ieO56mZDfSFMzjEHJAoeaE9jG3WRY9 qJf4y2qJB7n1BWW8rmiChEj9pt6PYG8Ot0jUEEv1Bp/tf5arx68sUZMiKfD6cCYXc+Rp anObfhdhyg96WpnATmRqNouM9CinkORfewwoSJuKFrUOZaUO0AFl9SzaQMPqnJ0jdD2N eEv3tZjPAwbxt9n3SqViSeLAZ6TaH/JmX5ghE2J10XwkqL9D5fA+AX2/XbZAJed5U8WP +rPQ== X-Gm-Message-State: AODbwcDkBswPZXltgyBLf9c7cKyFqSIn/nbXMjkSlH/Kx9B8GGCYo8nT xXySwqFkbpeoi0FR X-Received: by 10.55.144.194 with SMTP id s185mr2311040qkd.144.1494363535912; Tue, 09 May 2017 13:58:55 -0700 (PDT) Subject: Re: Simplify sendmmsg code To: Florian Weimer References: <2c061440-b7c4-985b-c9b9-05d17d952bc1@redhat.com> Cc: libc-alpha@sourceware.org, "Joseph S. Myers" From: Adhemerval Zanella Message-ID: <4926ca64-c33c-e72e-05fc-29d3f99f1144@linaro.org> Date: Tue, 09 May 2017 20:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2c061440-b7c4-985b-c9b9-05d17d952bc1@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00208.txt.bz2 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.