From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1aZipn-0001Mt-3U for mharc-grub-devel@gnu.org; Sat, 27 Feb 2016 12:39:15 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZipl-0001Lx-4E for grub-devel@gnu.org; Sat, 27 Feb 2016 12:39:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZipg-0004Vi-4R for grub-devel@gnu.org; Sat, 27 Feb 2016 12:39:13 -0500 Received: from mail-lb0-x233.google.com ([2a00:1450:4010:c04::233]:35106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZipf-0004Vc-NJ for grub-devel@gnu.org; Sat, 27 Feb 2016 12:39:08 -0500 Received: by mail-lb0-x233.google.com with SMTP id bc4so61267967lbc.2 for ; Sat, 27 Feb 2016 09:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=BAUzlWB4PQogf6wWTo4u4F10dWlq6FF0woEAlxrjHFQ=; b=h2bvC89WvcH7JsilC3q50vmHsXxLCWNPPLJZQHzqT2hXUAUMb5H8vq86ccZ2uD0VdJ 3BHg+uhHHHKByFIFT76z07ZOf0QqjmSlCFrrOlW/4aAQbMlpcU9k50MF5bDgLA+jnlG5 51GRlMfDXNZd3YuAk27QSWu+ewiKJ+iwJnHYyOr2QEALoNxV3CsUPtwJKesxW5JFBL7W Yva5A3uGuL4zqMZRm04D+cFS8gdsdMBZIvPsxZUQy/fJiLlJZKDTrwcLfM459rDhNYVb ICskL6APEeHk6Sv4JHI3RNXuqzL857AXLT+Rb4O9itmuVRz0XZmIVV2ToXJKpej1NRm3 k6uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=BAUzlWB4PQogf6wWTo4u4F10dWlq6FF0woEAlxrjHFQ=; b=BFZCBOdDqk5xQBw2Pf1mhQchiFHqLnyBB5YU43Q+xATGemoaGxI8U6VwlZAt/EGN+3 kmqr28qUA2t4DW1s36CdR1OQjJujzGtni+mMnkP/TnBClaLfb/FtTvCoqn6O4HSjQWpp 6IjAfJg9ulpwl0lZAcoaXYvBY3jaD9fY0BEziUk3NXjF7qsg6jV6/S2sBjNbVlp1zCkR esUs0ydgNI83wHtSoQyB27OQhgePUZmeK74vOMrv2IAgcPuvxD/2iTmvLO+Q9tPxH1lq yZH/Fc/kXgJ9QZy6aqzNCF1Xt3CYy79JxkEDpFDw8f03yNZ4p22cIQLGViYRRqe9mMB1 MATw== X-Gm-Message-State: AD7BkJJPSldZ2R7WehdM95v0mmTlLGyw7g87Y3kU3UJCfX8rpKqVxNtkFtRtuo8LadKa3Q== X-Received: by 10.112.72.101 with SMTP id c5mr2705310lbv.112.1456594746831; Sat, 27 Feb 2016 09:39:06 -0800 (PST) Received: from [192.168.1.41] (ppp109-252-76-159.pppoe.spdop.ru. [109.252.76.159]) by smtp.gmail.com with ESMTPSA id h72sm2660896lfe.33.2016.02.27.09.39.05 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 27 Feb 2016 09:39:05 -0800 (PST) Subject: Re: [PATCH] dns: realloc address buffer after each packet To: Josef Bacik , The development of GNU GRUB References: <1456341072-13356-1-git-send-email-jbacik@fb.com> <56D058B3.6060202@fb.com> From: Andrei Borzenkov X-Enigmail-Draft-Status: N1110 Message-ID: <56D1DF39.5060005@gmail.com> Date: Sat, 27 Feb 2016 20:39:05 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56D058B3.6060202@fb.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c04::233 Cc: Kernel Team X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2016 17:39:14 -0000 26.02.2016 16:52, Josef Bacik пишет: > On 02/26/2016 05:22 AM, Andrei Borzenkov wrote: >> On Wed, Feb 24, 2016 at 10:11 PM, Josef Bacik wrote: >>> Sometimes DNS responses come in slower than we poll for them which >>> can lead us >>> to process multiple DNS packets which overflows the addresses array. >>> So instead >>> realloc the array each time to make sure we are accounting for any >>> answers we >>> currently have in the address array. We also move the caching of the >>> addresses >>> outside of the recv hook so we can be sure to cache all the responses >>> at once >>> instead of one packet at a time. Thanks, >>> >> >> This still does not address the problem that we stop waiting for >> further packets as soon as we get any response, so we still depend on >> delivery order to get correct record. >> >> What about following >> >> - send both A and AAAA query concurrently if requested >> - keep track of both requests (i.e. have data.id[2] and >> data.addresses[2]) >> - reset request ID (or otherwise mark it as "received") as soon as we >> got reply. Note that reply may contain no addresses - NXDOMAIN is >> prerfectly valid - so condition should not be "got any record of type >> A or AAAA" as it is now but rather simply "got reply to request with >> id XX". This also allows us to implement negative caching at some >> point :) > > So we check the rcode so a NXDOMAIN response will just be discarded, we > don't have to worry about this case. > >> - return both A and AAAA results separately to grub_net_dns_lookup() >> - combine them in grub_net_dns_lookup() depending on preference - i.e. >> put either A or AAAA first in final result. >> >> This seems to cover all issues so far - we do not wait too long, we >> are guaranteed to get both A and AAAA if we request them and we return >> them in proper order for further processing. >> >> Do I miss something? >> > > So my patch previous to this one changes it so DNS servers we get from > dhcp are bound to either ipv4 or ipv6, so the only way we get > PREFER_IPV* is if an admin sets it. In this case I do not follow why you want to collect multiple answers in the first place. The only reason for me was to make sure we have both A and AAAA replies; otherwise every reply packet is supposed to contain exactly the same content. Following this logic the right thing to do is to just drop all subsequent duplicated replies. > So now the only time we'll get both > an A _and_ an AAAA record is if we have both types of interfaces on the > system, so it won't matter which answer is first as we'll be able to > send traffic to either. User can set preference using net_add_dns --prefer-ipvX | --only-ipvX. We should respect it. > I just side-stepped the issue by making it so > that (at least automatically) we aren't asking for both records unless > we are sure we have an interface to go along with both types of records. I'll reply to your other patch.