From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 8006A3858C83 for ; Tue, 4 Oct 2022 16:32:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8006A3858C83 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664901173; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qVtiPd5tmF2S78tX51+Tj/KNY110goMN84DNjQC2OM8=; b=VRjOcPVjDMy38K38vFVi98vXdUEbIj/5In68rxhTQmZhEjAJ6hTfZvHaGEqiFOpjP88W4H ktV/3ssTMtIJ7L9GVLL9tDA8Bck0ynLKJ7Apo/puVcmTnlMDPESoAhGw7lEJ+u2gPPjCEP 7/L/n/nGRobd4K8x96ZBoJ76TumN73o= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-149-tqOK2sgIPvKdrafS3vkuzg-1; Tue, 04 Oct 2022 12:32:52 -0400 X-MC-Unique: tqOK2sgIPvKdrafS3vkuzg-1 Received: by mail-qt1-f199.google.com with SMTP id u9-20020a05622a14c900b0035cc7e8cbaeso9692749qtx.19 for ; Tue, 04 Oct 2022 09:32:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date; bh=qVtiPd5tmF2S78tX51+Tj/KNY110goMN84DNjQC2OM8=; b=tw0es9szX9lAu3XFBo77U+XBdTM3uGgpFLb1qm2g++75Om4G1NcLsJBlTDapWI4AZf erYyO9JAYaHiw+Yaq/ZDtrVFARXOMXG94ExhnGXcTN4+MzIHOZNpuMF6fXwuHJwax41P PR9LUt/hLQiKqlJR4zgWSAFcooJIGSECaa1fEexmk0l5IQPk56ztQjxg+CRGf9vDsSWU ypbWVn7Eyg+LCF+9ONSsUlr1WXTPLkNpoRTaeNggMAAZkp8QweoNXQLaummKEprHJ/zY I4BQRJuGl7ZqnQVE4d9nTY4IrYvYVaT0wzHB14q3ogE2PAQ6NX9lqzPHvLN6gTyoig93 H5PA== X-Gm-Message-State: ACrzQf0N2pNEker2UzWtcw6o0tfmF6SIqPnVjL5fY21iLExllU5yTK+4 faQzAiWmJJwJ1zjab1sUmQUyxHS9vt3c0sEIcceCZriK5BS7kUQC9xSz9Kfhl6dCYcjfSSMLR9r MuW+l2WnalZ06YkONYPsm X-Received: by 2002:a05:622a:50c:b0:35d:5ab8:b43e with SMTP id l12-20020a05622a050c00b0035d5ab8b43emr20062793qtx.440.1664901171284; Tue, 04 Oct 2022 09:32:51 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6JgNz4+jg/GZsgt36Ef3E2qVoEv4ezfCraVEuLeyXm7MRVdDBbi3nJA4ZGFsc9vz6M0zlwJA== X-Received: by 2002:a05:622a:50c:b0:35d:5ab8:b43e with SMTP id l12-20020a05622a050c00b0035d5ab8b43emr20062778qtx.440.1664901171059; Tue, 04 Oct 2022 09:32:51 -0700 (PDT) Received: from fedora ([66.187.232.65]) by smtp.gmail.com with ESMTPSA id b9-20020a05622a020900b0035d430d4315sm12707584qtx.19.2022.10.04.09.32.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Oct 2022 09:32:50 -0700 (PDT) Date: Tue, 4 Oct 2022 12:32:47 -0400 From: Carlos O'Donell To: Siddhesh Poyarekar Cc: libc-alpha@sourceware.org, Holger =?iso-8859-1?Q?Hoffst=E4tte?= Subject: Re: [PATCH] nscd: Drop local address tuple variable [BZ #29607] Message-ID: References: <20221004000657.1940145-1-siddhesh@sourceware.org> MIME-Version: 1.0 In-Reply-To: <20221004000657.1940145-1-siddhesh@sourceware.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=WINDOWS-1252 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-12.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Oct 03, 2022 at 08:06:57PM -0400, Siddhesh Poyarekar via Libc-alpha wrote: > When a request needs to be resent (e.g. due to insufficient buffer > space), the references to subsequent tuples in the local variable are > stale and should not be used. This used to work by accident before, but > since 1d495912a it no longer does. Instead of trying to reset it, just > let gethostbyname4_r write into TUMPBUF6 for us, thus maintaining a > consistent state at all times. This is now consistent with what is done > in gaih_inet for getaddrinfo. LGTM. Reviewed-by: Carlos O'Donell > Resolves: BZ #29607 > Reported-by: Holger Hoffstätte > --- > > Tested on x86_64 with Fedora and nscd enabled. Testing with other > distributions would be really appreciated! > > Thanks, > Sid > > > nscd/aicache.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/nscd/aicache.c b/nscd/aicache.c > index 51e793199f..e0baed170b 100644 > --- a/nscd/aicache.c > +++ b/nscd/aicache.c > @@ -110,11 +110,10 @@ addhstaiX (struct database_dyn *db, int fd, request_header *req, > "gethostbyname4_r"); > if (fct4 != NULL) > { > - struct gaih_addrtuple atmem; OK. Remove the single static struct (no longer used). > struct gaih_addrtuple *at; > while (1) > { > - at = &atmem; > + at = NULL; OK. Start with at NULL. > rc6 = 0; > herrno = 0; > status[1] = DL_CALL_FCT (fct4, (key, &at, > @@ -137,7 +136,7 @@ addhstaiX (struct database_dyn *db, int fd, request_header *req, > goto next_nip; > > /* We found the data. Count the addresses and the size. */ > - for (const struct gaih_addrtuple *at2 = at = &atmem; at2 != NULL; > + for (const struct gaih_addrtuple *at2 = at; at2 != NULL; OK. Remove &atmem. We set at2 to at. In all of these cases the memory is created by alloc_create_buffer() and the memory for the gaih_addrtuple comes from that buffer. We don't want to reset to &atmem sine this is no longer correct. The allocation is done at the lowest level in fct4. > at2 = at2->next) > { > ++naddrs; > -- > 2.37.2 >