From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7EFDCC55179 for ; Tue, 27 Oct 2020 13:14:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 344A520809 for ; Tue, 27 Oct 2020 13:14:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="bbdR283h" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2900533AbgJ0NOJ (ORCPT ); Tue, 27 Oct 2020 09:14:09 -0400 Received: from mail-ej1-f67.google.com ([209.85.218.67]:45723 "EHLO mail-ej1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2900513AbgJ0NOH (ORCPT ); Tue, 27 Oct 2020 09:14:07 -0400 Received: by mail-ej1-f67.google.com with SMTP id dt13so2122901ejb.12; Tue, 27 Oct 2020 06:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tXCh10L6SQ/i1jAypyelKxw6+jw7G2ndnRAA6TkZnhQ=; b=bbdR283hpRGZjvgIPzlZojPzICFZFefNUuU5ZTlnsljeK+GFNOK7wCkzS+drlzHePv g+hz5vMd0UqX5sfyP/Ykd2OekHy/yUcHcugq1BA0hVTv3fuiYpDof8I2xYYV2fL59aPD Vr9fXAW/9YJSSBYiRN3cgyG0FapXrD+codJhGe8srHeEQXSJNxhT17h2wVqEDJpxDwHB xD7q/2ySeRc0dA1BYSA8Xyg7PwQgKLUKyzZF+I0hC7HjGnxa9prORGUnCdUkEM7UXFPo CQHANjdy6ZIQyBS8syaW7BOYCa1fU1lazGllPME/IPJ4IftHghTSqnUQelV3djkEoPCB ybTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tXCh10L6SQ/i1jAypyelKxw6+jw7G2ndnRAA6TkZnhQ=; b=FA1JgR/NCfji4bCrgmMpWBCVf2e6WRwymjTpwtoFjVcPHosuDgGdSWH5lpl2Am6mmp ODk6Y8OUDNsz4WED2B4/WMikwbQ3KOFvQrh0BTnOoUHqQttKuwUqpoQU/1KqGZnLoSh3 jC+FJUgBk6b/I2G0D35bdU/U976lCexuPrVuqYccy6fCQ4v1jlt/XZqr+K1RyvvS6fle qeMXK8lqV2HOQEm+LqCRkzwcjutWwqM/RiBnTxqZS0667SHj+a65BE2gF/pIxPpLqSRr t2coUoNd+46R3UkllzK+inoKauz2MvNZk8gEASXYnKo1AopbOzp+RDdQWwIWcm3nfWPB qDHw== X-Gm-Message-State: AOAM530Q+lnAGsPAe1dhU8ijYeAItM3n9pD/xDMy9EZRzssRPTQFfq5Z 97E0Zz7te++r1Y7F6PzAw40mRb426lmEOYVHvjU= X-Google-Smtp-Source: ABdhPJxcm0RqztaYgbxFJmGIMA54GBLWoYl6lPTvCEjRgI13WS0Rexa+oJAp1pAe9g59yXpGqTrGVZ4eNr5FNBvZb1c= X-Received: by 2002:a17:907:204c:: with SMTP id pg12mr2239886ejb.464.1603804444784; Tue, 27 Oct 2020 06:14:04 -0700 (PDT) MIME-Version: 1.0 References: <20201026150851.528148-1-aleksandrnogikh@gmail.com> <20201026150851.528148-3-aleksandrnogikh@gmail.com> In-Reply-To: From: Willem de Bruijn Date: Tue, 27 Oct 2020 09:13:29 -0400 Message-ID: Subject: Re: [PATCH v3 2/3] net: add kcov handle to skb extensions To: Aleksandr Nogikh Cc: Aleksandr Nogikh , David Miller , Jakub Kicinski , Johannes Berg , Eric Dumazet , Andrey Konovalov , Dmitry Vyukov , Marco Elver , linux-kernel , Network Development , linux-wireless Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Oct 27, 2020 at 8:31 AM Aleksandr Nogikh wrote: > > On Mon, Oct 26, 2020 at 7:57 PM Willem de Bruijn > wrote: > [...] > > If the handle does not need to be set if zero, why then set it if the > > skb has extensions? > > The point of that condition is to avoid unnecessary allocations of skb ex= tension > objects. At the same time, one would expect skb_get_kcov_handle to return= the > latest value that was set via skb_set_kcov_handle. So if a buffer already= has a > non-zero kcov_handle and skb_set_kcov_handle is called to set it to zero,= it > should be set to zero. I see. I thought it was some best effort approach: if there happens to be space, use it, but don't allocate. Which I did not understand. Could you rephrase the comment to make more clear that this is about clearing a possibly previously set value. > > skb_ext_add and skb_ext_find are not defined unless CONFIG_SKB_EXTENSIO= NS. > > > > Perhaps CONFIG_KCOV should be made to select that? > > Yes, thank you for pointing it out. I=E2=80=99ll fix it in the next versi= on.