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=-5.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 5D11DC64E69 for ; Thu, 19 Nov 2020 22:05:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0378122256 for ; Thu, 19 Nov 2020 22:05:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="jZ3KTQBK" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726863AbgKSWF0 (ORCPT ); Thu, 19 Nov 2020 17:05:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726497AbgKSWFY (ORCPT ); Thu, 19 Nov 2020 17:05:24 -0500 Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0CACBC0613CF for ; Thu, 19 Nov 2020 14:05:23 -0800 (PST) Received: by mail-lf1-x143.google.com with SMTP id s30so10555100lfc.4 for ; Thu, 19 Nov 2020 14:05:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=caVbQJgTNUd3ZyBW7a7yHO/mVe+/+dynQ8Kf/1ZeYWM=; b=jZ3KTQBKpps0OPiXvYOFLRGYnVQSV8UQx5Naaeo4ejKpoO68Nap6Q/ZOeoAuRo9dJI +k6J/WmjgoZ5TEHw9YkYFm0Oh5vB1p4PAYgmRroQD1P8MKDua1PuOix1olFyLDSyx/o5 ltLlZKvBklVAuDrt9VCsiX6xp3ANEd8LHmnIk= 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; bh=caVbQJgTNUd3ZyBW7a7yHO/mVe+/+dynQ8Kf/1ZeYWM=; b=dvGpiaohKLcmBRX2MSninCY/WahJD65kfsMcrPahnw+1BHUZeAJYU7zo5NAMDzsU4q l2gZG9SM1EJcb/JpS3O7wrbj2bZtCos09LQnJsSC7R8YQvlZpOuYw23r5kJMu73EdsQ0 L4kacqKWx/5it+SOfBjoy1f6hFm5xUk9CjR4hqNzQts894F7iZYlo0p21G67+88zgN46 yoh04I68f5aVSOKrU00dyIETPQAVWr9m4kh9QJ73jJq1nvxd6citbnAAg95XOXVEIcqM L04Vu4xQhxjdgGw0k7mm2SpXLX8OhuaTeB1qLXzB7sp3KHT+DwyqLtS0RK8I6rfJb3U4 b34g== X-Gm-Message-State: AOAM530tjiis6ZskWIJIDFFmQ+ooK5jxI1tl31CfvrUbzSI1hGu/iwGp +y5fwSZqY5Pl+33ISMael80i/ooTKerua0yqt01TeQ== X-Google-Smtp-Source: ABdhPJykoD4e40Ht9VbmfCWlQEro37Hq5PyVDkPKQiE1le37+k8HUvT460q+r8/KCm8efY+hU9FmjEhGTBZs65Br5mo= X-Received: by 2002:ac2:5591:: with SMTP id v17mr6402331lfg.562.1605823521321; Thu, 19 Nov 2020 14:05:21 -0800 (PST) MIME-Version: 1.0 References: <20201119162654.2410685-1-revest@chromium.org> <20201119162654.2410685-3-revest@chromium.org> In-Reply-To: <20201119162654.2410685-3-revest@chromium.org> From: KP Singh Date: Thu, 19 Nov 2020 23:05:10 +0100 Message-ID: Subject: Re: [PATCH v2 3/5] bpf: Expose bpf_sk_storage_* to iterator programs To: Florent Revest Cc: bpf , Al Viro , "David S. Miller" , Jakub Kicinski , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Yonghong Song , Andrii Nakryiko , Florent Revest , open list , Networking Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 19, 2020 at 5:27 PM Florent Revest wrote: > > From: Florent Revest > > Iterators are currently used to expose kernel information to userspace > over fast procfs-like files but iterators could also be used to > manipulate local storage. For example, the task_file iterator could be > used to initialize a socket local storage with associations between > processes and sockets or to selectively delete local storage values. > > This exposes both socket local storage helpers to all iterators. > Alternatively we could expose it to only certain iterators with strcmps > on prog->aux->attach_func_name. Since you mentioned the alternative here, maybe you can also explain why you chose the current approach.