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=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 EFBEEC4360F for ; Mon, 4 Mar 2019 22:28:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C725520823 for ; Mon, 4 Mar 2019 22:28:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726531AbfCDW2S convert rfc822-to-8bit (ORCPT ); Mon, 4 Mar 2019 17:28:18 -0500 Received: from mail-ed1-f68.google.com ([209.85.208.68]:41233 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726076AbfCDW2R (ORCPT ); Mon, 4 Mar 2019 17:28:17 -0500 Received: by mail-ed1-f68.google.com with SMTP id x7so5570285eds.8 for ; Mon, 04 Mar 2019 14:28:16 -0800 (PST) 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:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=XxUye7U99Yja6dlIrub9AyVQyuSVvxpoJofEpVQEwGA=; b=EJe7TOri+pfmTkMimXyi3i+hiQwyebCAh7nyiChldkjxfJCvfJZV0PM4Tya1fQa/pF gGgmniJ3EnoMZ/MJdHEOyV/n6HtxaUB4qri6Aq8igwSz1Y5LZ0zJSfyaRG+MeqfQdFRj c43st2c6oV6zisEuFFHl2a/eX4ZHhxvGI09/S9AAeuA911nX94AdvUhzluqOiNzyesfP RmgL5OS7TKx2VafmPxOAc33ja/aCbsI5b/BXc43Ze22nabxobBJVf7zDR4ssPlhp6ZfU zMyLibDcvVdSnT7VbGqC7ZGtlLaVROK/kIF3qMCQq1r8PpwbZ2UPO03/X0w5BUCVfuq4 GaVA== X-Gm-Message-State: APjAAAVr84l1fpSV52+Fsl+7dYY+wkmf+cTlZHtcDOJ90G/zR7/kpek2 IkmMOU0HeFnsNayzRQ+FbMI5IQ== X-Google-Smtp-Source: APXvYqxz6gJYO4jU/8DzflGaZ4mKWnCChnMlM+0YYGW9UIDIS/AyERvCXx81Q8RSKFqh6W23qUY1wg== X-Received: by 2002:a17:906:d552:: with SMTP id gk18mr14168084ejb.55.1551738495579; Mon, 04 Mar 2019 14:28:15 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk (alrua-x1.vpn.toke.dk. [2a00:7660:6da:10::2]) by smtp.gmail.com with ESMTPSA id d42sm2486127ede.30.2019.03.04.14.28.15 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 04 Mar 2019 14:28:15 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id BA09B182E8E; Mon, 4 Mar 2019 23:28:14 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Jakub Kicinski Cc: David Miller , netdev@vger.kernel.org, Jesper Dangaard Brouer , Daniel Borkmann , Alexei Starovoitov Subject: Re: [PATCH net-next v3 2/3] xdp: Always use a devmap for XDP_REDIRECT to a device In-Reply-To: <20190304141558.061824a7@cakuba.netronome.com> References: <155144955030.28287.14029975169967438162.stgit@alrua-x1> <155144955045.28287.6187020206969282688.stgit@alrua-x1> <20190301180945.1152c6de@cakuba.netronome.com> <877edelukk.fsf@toke.dk> <20190304094452.375ba6e7@cakuba.netronome.com> <87fts231fp.fsf@toke.dk> <20190304141558.061824a7@cakuba.netronome.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Mon, 04 Mar 2019 23:28:14 +0100 Message-ID: <877ede2s1t.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Jakub Kicinski writes: > On Mon, 04 Mar 2019 20:05:30 +0100, Toke Høiland-Jørgensen wrote: >> > Hm. I think you'll still need a lock (mutex?) on the alloc path, but >> > the free path should be fine as long as you load the map pointer before >> > looking at the refcnt (atomic op ensuring the barrier there). >> >> Yeah, for the per-namespace refcnt it's pretty straight forward, the >> trouble is the global count that needs to iterate over all namespaces; >> probably need to put that all behind a (non-spin)lock, right? > > Because net iteration is under RCU? You can switch to taking net_rwsem > for that one, no? I'm probably confused again ;) Because there's a single refcount that needs to trigger creation/deletion of *all* the default maps. I.e. if (atomic_dec_return(&global_refcnt)) for_each_namespace(net) destroy_default_map(net); which needs to not step on the toes of a subsequent if (atomic_inc_return(&global_refcnt) == 1) for_each_namespace(net) create_default_map(net); (or vice versa, of course). Not sure there's a way to do that without wrapping both of those constructs (including the refcnt inc/dec) in a mutex? -Toke