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=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,FROM_EXCESS_BASE64, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 B0970C282D8 for ; Fri, 1 Feb 2019 21:47:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7A05720863 for ; Fri, 1 Feb 2019 21:47:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="RQdQVF7I" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726563AbfBAVr1 (ORCPT ); Fri, 1 Feb 2019 16:47:27 -0500 Received: from mail-lf1-f67.google.com ([209.85.167.67]:34162 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726275AbfBAVr1 (ORCPT ); Fri, 1 Feb 2019 16:47:27 -0500 Received: by mail-lf1-f67.google.com with SMTP id p6so6197274lfc.1 for ; Fri, 01 Feb 2019 13:47:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=fHpvRH1dC/3Im66U/W8EK/uo2ZHhAzmhDpeiXgfwSKY=; b=RQdQVF7I01sXh6EhKUGmocw5xMc84IZOwrzijNvQ84iARHhlP6bA0Y86+AlkggeY+l Fbar2n7RJNPE35tsoWkgmSzjyrEVV6PPt9GOPSj85/xn6GZjJb3eYh9RddWkrqvThrBm sjNL2IiMgq98MOrO4i93+OYQxKU5H70qqjh0HfNHN4tSQwea7GfhsGtADRcNaCoAFJSl UkG8/B0mPrs8PNGT2Vm2iROlq9rnIxKO3EO/BQI5Lw/ITqjd57iVz11CaDReg93lEVcK pzwDMzE0AccfcVfrSkioPdrpk8UryiucjDNBii/PJKBYmlUDt5kV8dluH+IFOzh/eDWj /+Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=fHpvRH1dC/3Im66U/W8EK/uo2ZHhAzmhDpeiXgfwSKY=; b=QK8/5WSyR5Ux+SLqiH3+CboVf+f4IMzwB9GJoIxi4kCVLcqCYZyzCt18d5volqrD2C vftVGNpxXfveAnyNyyZU+DsizKyvB5zQcIifnrxj3qTi4FfweU42q1o0rMLS05u53gAT FjeEDhieQqWlSy6Raow7iHDZ91g4alpR82XFnouThfPcTYGiS67GFK9kae6eihfX74db Iyih8FdBfUWOnlMGhy2L9SRmnd2/54zSAcpuMg/GdhkHsMYYx8ogaw6Yi+IlFdJ80qXL D4e9L5n0Ih4KZVYRksf6s7MzERKhUsVpYtIJzDroUZj+fqndDjc7p6vGGbcktUQa+FD1 107Q== X-Gm-Message-State: AJcUukfA3WxJBkCTfKVlYynxkJSU87+iVY9HXd5fSzoyTPyWJSe5v1Pk oFsEw2b1T8cawAylVUUbev4ZXyHt X-Google-Smtp-Source: ALg8bN63c3ZfunSvqIzeTqKBdUQEtGcFJU3PuHh8xmPlnkP3g2wWZeRHC2PaOg5mPydsJ6LP2ZMbxQ== X-Received: by 2002:a19:c954:: with SMTP id z81mr32508828lff.150.1549057644998; Fri, 01 Feb 2019 13:47:24 -0800 (PST) Received: from maciek-lenovo (host-185-93-94-63.ip-point.pl. [185.93.94.63]) by smtp.gmail.com with ESMTPSA id t11sm315505lfk.88.2019.02.01.13.47.24 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 01 Feb 2019 13:47:24 -0800 (PST) Date: Fri, 1 Feb 2019 22:47:20 +0100 From: Maciej =?UTF-8?B?RmlqYcWCa293c2tp?= To: Daniel Borkmann Cc: ast@kernel.org, netdev@vger.kernel.org, jakub.kicinski@netronome.com, brouer@redhat.com, john.fastabend@gmail.com Subject: Re: [PATCH bpf-next v5 0/8] xdp: Avoid unloading xdp prog not attached by sample Message-ID: <20190201224720.3b4a1b5a@maciek-lenovo> In-Reply-To: <1221854d-a2ad-cc03-8e72-985a265c49c9@iogearbox.net> References: <20190201001954.4130-1-maciej.fijalkowski@intel.com> <1221854d-a2ad-cc03-8e72-985a265c49c9@iogearbox.net> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, 1 Feb 2019 22:23:45 +0100 Daniel Borkmann wrote: > On 02/01/2019 01:19 AM, Maciej Fijalkowski wrote: > > Hi! > > This patchset tries to address the situation where: > > * user loads a particular xdp sample application that does stats polling > > * user loads another sample application on the same interface > > * then, user sends SIGINT/SIGTERM to the app that was attached as a first > > one > > * second application ends up with an unloaded xdp program > > > > 1st patch contains a helper libbpf function for getting the map fd by a > > given map name. > > In patch 2 Jesper removes the read_trace_pipe usage from xdp_redirect_cpu > > which was a blocker for converting this sample to libbpf usage. > > 3rd patch updates a bunch of xdp samples to make the use of libbpf. > > Patch 4 adjusts RLIMIT_MEMLOCK for two samples touched in this patchset. > > In patch 5 extack messages are added for cases where dev_change_xdp_fd > > returns with an error so user has an idea what was the reason for not > > attaching the xdp program onto interface. > > Patch 6 makes the samples behavior similar to what iproute2 does when > > loading xdp prog - the "force" flag is introduced. > > Patch 7 introduces the libbpf function that will query the driver from > > userspace about the currently attached xdp prog id. > > > > Use it in samples that do polling by checking the prog id in signal handler > > and comparing it with previously stored one which is the scope of patch 8. > > > > Thanks! > > > > v1->v2: > > * add a libbpf helper for getting a prog via relative index > > * include xdp_redirect_cpu into conversion > > > > v2->v3: mostly addressing Daniel's/Jesper's comments > > * get rid of the helper from v1->v2 > > * feed the xdp_redirect_cpu with program name instead of number > > > > v3->v4: > > * fix help message in xdp_sample_pkts > > > > v4->v5: > > * in get_link_xdp_fd, assign prog_id only when libbpf_nl_get_link returned > > with 0 > > * add extack messages in dev_change_xdp_fd > > * check the return value of bpf_get_link_xdp_id when exiting from sample > > progs > > Series looks good to me, but doesn't apply cleanly, please rebase. > > Thanks, > Daniel Sure, sending v6 in a minute.