Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3815172ybb; Mon, 6 Apr 2020 16:40:50 -0700 (PDT) X-Google-Smtp-Source: APiQypIq9HHuU1TCAar/pQW7PcBs4boaiftkmvy2HKuqMsoWaEtI2mgw3fjUfO8Fqv1aKV6vMIKc X-Received: by 2002:a9d:6857:: with SMTP id c23mr19765825oto.224.1586216449986; Mon, 06 Apr 2020 16:40:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586216449; cv=none; d=google.com; s=arc-20160816; b=LV43UUPVWZOBw8iIQK8GYfkcHkAWIoJ5h3Y2QhgBlDyMrLuJawkDJxEWHykmmVeNf5 EmH1YmvD93BV30gcu7jIOgTI5VYtgthGpksWvaR07L3gbS5u7fBduaS4SuDSDwapL1KG v+qoR4k/0jciH29PN1ot91nndrn4mBSrFzBYTpP5S6hOGesk4rSVpn/MnIZll+NzuHgJ 6b3VU5r8/EseoL92DnNzPSoLylZ5syLzYGycDtvk8uqSFhSXVXZ8DjLdznruXJ0zAOn2 EBzW5XYB1mpZn87EhIn4P1LkDGaJEMGI94wJk13snAo4rd6lgGQLwJnhMK8pbcZxM/Ke mLng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:dkim-signature; bh=WM8xDoDQ9iS/jeeUYD4yS2C0/dqqITfA49gu7xf3zpk=; b=Qh7JKxdYUfj3nEVbDCirMOjElvxlKpcQ/UP4LVFJg+ebegyMQEvC1OwOl3/aTVFcc9 J03BKauUXvf8FxEl15qc6wjKPV+wt2bwLq34pDpPkePcz6RlQkDQT4vfpqE8Zp7PYZ/x bFz42e/29YugKhG6DDzyuaYK7vEtf+vMl3PJApXQyuKsondtL8/5X6BRdKtws96itnLH Vs0pXXcj/TfKaATMwzczt+MJ1M6P4E0bJx0zY0b2PvnhuYWDd3+vCsFgCvXnu4yKH95V YtZBExzlgCtcarTgosUOcAPZRihTybszrdLglqbPhOoPBekkDTjc1I5sh9pCVj8z32iB Wzpw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZCaQK6kR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f1si506576oti.125.2020.04.06.16.40.36; Mon, 06 Apr 2020 16:40:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZCaQK6kR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726312AbgDFXkF (ORCPT + 99 others); Mon, 6 Apr 2020 19:40:05 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:41618 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726254AbgDFXkF (ORCPT ); Mon, 6 Apr 2020 19:40:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586216404; 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=WM8xDoDQ9iS/jeeUYD4yS2C0/dqqITfA49gu7xf3zpk=; b=ZCaQK6kRrM+dNYaeYmJlZ5CLB/VZqCIF63UFZGIaTZZ5Maw47aWj9INpjx5DXujeEzESui YwOQ6yL41yL49DfJZov/TL27kq6/dGtmCDxZzmQA40+WhrY2UeTJtCa64IIzwPFwje84y6 Eq3ugvU8M5YOtwJpnWxBUS091w64mjE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-21-IKF6aZ_eNCy6plDcCa3dfQ-1; Mon, 06 Apr 2020 19:40:02 -0400 X-MC-Unique: IKF6aZ_eNCy6plDcCa3dfQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 40E43800D5C; Mon, 6 Apr 2020 23:40:00 +0000 (UTC) Received: from localhost (unknown [10.36.110.15]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CEC265D9C5; Mon, 6 Apr 2020 23:39:56 +0000 (UTC) Date: Tue, 7 Apr 2020 01:39:51 +0200 From: Stefano Brivio To: Colin King Cc: Pablo Neira Ayuso , Jozsef Kadlecsik , Florian Westphal , "David S . Miller" , Jakub Kicinski , netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev@vger.kernel.org, kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] nft_set_pipapo: remove unused pointer lt Message-ID: <20200407013951.77a6409f@redhat.com> In-Reply-To: <20200406232031.657615-1-colin.king@canonical.com> References: <20200406232031.657615-1-colin.king@canonical.com> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Colin, On Tue, 7 Apr 2020 00:20:31 +0100 Colin King wrote: > From: Colin Ian King > > Pointer lt being assigned with a value that is never read and > the pointer is redundant and can be removed. > > Addresses-Coverity: ("Unused value") > Signed-off-by: Colin Ian King > --- > net/netfilter/nft_set_pipapo_avx2.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/net/netfilter/nft_set_pipapo_avx2.c b/net/netfilter/nft_set_pipapo_avx2.c > index d65ae0e23028..9458c6b6ea04 100644 > --- a/net/netfilter/nft_set_pipapo_avx2.c > +++ b/net/netfilter/nft_set_pipapo_avx2.c > @@ -1049,11 +1049,9 @@ static int nft_pipapo_avx2_lookup_slow(unsigned long *map, unsigned long *fill, > struct nft_pipapo_field *f, int offset, > const u8 *pkt, bool first, bool last) > { > - unsigned long *lt = f->lt, bsize = f->bsize; > + unsigned long bsize = f->bsize; > int i, ret = -1, b; > > - lt += offset * NFT_PIPAPO_LONGS_PER_M256; > - > if (first) > memset(map, 0xff, bsize * sizeof(*map)); > for (i = offset; i < bsize; i++) { if (f->bb == 8) pipapo_and_field_buckets_8bit(f, map, pkt); else pipapo_and_field_buckets_4bit(f, map, pkt); Now, this function should never be called, it's provided as a safety net in case this algorithm is ever run with some strange packet field size, still, your clean-up shows another "issue" here: as pipapo_and_field_buckets_*() functions use the full buckets in lookup tables, not just starting from an offset, there's no need to repeat those operations starting from offset up to bsize. It's fine to ignore the offset (which is just a "hint" here for faster lookups) -- this function isn't supposed to be optimised in any way. That is, this for loop should go away altogether, and the 'offset' argument should be dropped as well. Let me know if you're comfortable taking care of that as well, or if you prefer that I send a patch. -- Stefano