From patchwork Thu Jan 17 01:01:09 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maciej Fijalkowski X-Patchwork-Id: 1026360 Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="Bw1JEdkM"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 43g5Q72Vk2z9sCh for ; Thu, 17 Jan 2019 12:02:07 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727278AbfAQBCG (ORCPT ); Wed, 16 Jan 2019 20:02:06 -0500 Received: from mail-lj1-f196.google.com ([209.85.208.196]:38745 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725888AbfAQBCF (ORCPT ); Wed, 16 Jan 2019 20:02:05 -0500 Received: by mail-lj1-f196.google.com with SMTP id c19-v6so7105412lja.5 for ; Wed, 16 Jan 2019 17:02:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=niJJ19jB/rIIhboSl3m5htQEwurXs9YwFBuKlNFIGUQ=; b=Bw1JEdkMThetURizrD4/zj6Tj9kSXmi1LwX9JF9DWY82utNo4W8aOwkQ5KlyxIYA4F iNWo5qSmbjj10k43rpQxpxeBvqhihv68+sVvfmDG4oyZcHCAbQDd9but+ZoRh5OZdQ6F Ic6h6saHkOr0TO8w8gASRzECQnUpzePV3xAEmlxYaGsRh7TqZdyl80IhSrTBjPUgaYjt gVTYlIjUIfAg+7fiYI9IE7FcKzyEJWhuRFFjX3YWXCLzezomnEwGo7quEYkjo3H8YmAh FSl76AToUt1fM2CKxYSz3sHQJI4Bidzi+vf6WQBew+3e+jNR/GJ1qe09+nlc+ilze5nr 38Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=niJJ19jB/rIIhboSl3m5htQEwurXs9YwFBuKlNFIGUQ=; b=FO4H3sbTGjbbu0VnJ6RsRdPotusjSA7FUjHvfoBkxQSCgDTWEQbinWBN/l7JLiZgDr 5ZqRajN5CJtFXjkQBxf3e5BxNVom5NrMa9LrRMlLKWF94jGpDE9ncKpr5jhPtgxuXfTF RQ4EnqpvzTIR5Q1sTU32dDFrxdCmw2MQIMAXfrCAJcPSC2xCDwOmQ6C06Nm3BQOpLCva nNWRLCkqrMKd7/+RqOpd+qyoe5fycefKA0cwufJEaOGqpXpAPMDajg3okGMwkiWdvtYj LwsZWBjzd+7kpgr9vwHgJuIlV/Xw2sOmxrkXht1ZQuyHY2gCtQOxdhFMq1gvQnk9ToXX uTbg== X-Gm-Message-State: AJcUukdbPMxLcNQyc4TZD3LQoDNrYJZQGW9vu8bisYF0BNJAL1ETe7iA hxiHI0FLq1vidEjab0U3uUs= X-Google-Smtp-Source: ALg8bN5t411ZNuwNSWk9lvijyDldvHaAz+D6EhYY+iQvVcM1xl17RBcFnhYJ4ZufGesuzOXYm6qD3g== X-Received: by 2002:a2e:9849:: with SMTP id e9-v6mr8428547ljj.9.1547686923616; Wed, 16 Jan 2019 17:02:03 -0800 (PST) Received: from localhost.localdomain (host-185-93-94-63.ip-point.pl. [185.93.94.63]) by smtp.gmail.com with ESMTPSA id l17sm4341lfk.40.2019.01.16.17.02.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Jan 2019 17:02:03 -0800 (PST) From: Maciej Fijalkowski To: daniel@iogearbox.net, ast@kernel.org Cc: netdev@vger.kernel.org, jakub.kicinski@netronome.com, brouer@redhat.com Subject: [PATCH bpf-next 0/6] xdp: Avoid unloading xdp prog not attached by sample Date: Thu, 17 Jan 2019 02:01:09 +0100 Message-Id: <20190117010115.18234-1-maciejromanfijalkowski@gmail.com> X-Mailer: git-send-email 2.16.1 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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. 2nd patch updates a bunch of xdp samples to make the use of libbpf. Patch 3 adjusts RLIMIT_MEMLOCK for two samples touched in this patchset. Patch 4 makes the samples behavior similar to what iproute2 does when loading xdp prog - the "force" flag is introduced. Patch 5 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 6th patch. Thanks! Maciej Fijalkowski (6): libbpf: Add a helper for retrieving a map fd for a given name samples: bpf: Convert XDP samples to libbpf usage samples: bpf: Extend RLIMIT_MEMLOCK for xdp_{sample_pkts, router_ipv4} samples: bpf: Add a "force" flag to XDP samples libbpf: Add a support for getting xdp prog id on ifindex samples: bpf: Check the prog id before exiting samples/bpf/Makefile | 8 +- samples/bpf/xdp1_user.c | 29 +++++- samples/bpf/xdp_adjust_tail_user.c | 33 +++++-- samples/bpf/xdp_redirect_map_user.c | 94 ++++++++++++++++---- samples/bpf/xdp_redirect_user.c | 92 +++++++++++++++---- samples/bpf/xdp_router_ipv4_user.c | 171 +++++++++++++++++++++++++----------- samples/bpf/xdp_rxq_info_user.c | 36 ++++++-- samples/bpf/xdp_sample_pkts_user.c | 76 +++++++++++++--- samples/bpf/xdp_tx_iptunnel_user.c | 66 ++++++++++---- samples/bpf/xdpsock_user.c | 25 +++++- tools/lib/bpf/libbpf.c | 12 +++ tools/lib/bpf/libbpf.h | 4 + tools/lib/bpf/libbpf.map | 5 ++ tools/lib/bpf/netlink.c | 84 ++++++++++++++++++ 14 files changed, 598 insertions(+), 137 deletions(-)