From patchwork Fri Mar 24 10:02:22 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Nuno_Gon=C3=A7alves?= X-Patchwork-Id: 13186623 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 452BAC76196 for ; Fri, 24 Mar 2023 10:02:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231267AbjCXKCu (ORCPT ); Fri, 24 Mar 2023 06:02:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57846 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231411AbjCXKCr (ORCPT ); Fri, 24 Mar 2023 06:02:47 -0400 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED75823C4A for ; Fri, 24 Mar 2023 03:02:42 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id g17so1489635lfv.4 for ; Fri, 24 Mar 2023 03:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fr24.com; s=google; t=1679652161; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=hqniG2RTuzYc41TgGVo3CFmOEDPj8x/ry7qdxr2ig3U=; b=WdI66PJPmXPEQ9JwFdMZEGzbWsV7VQNXtqHY0IP5KW3ugIT1HddLLFCZGJiW+0fXBb acjfwE58oDPoFP7rSLsBqLYWet8dEnJR4hojFRxQSooIUzKmz4r5C9IPF2+YdVyfqzas 6q99o1Fh4jZ8c0agitV0Og+EynCvHsrEpn0Gh5nMyQUIsFkNumPNWlNkYWL4nit46dJa RKpVlISZwv1/YbooAg7Rfz8nR8W7MyR46ZDSvEL6PtuKDXtHvjKDJ6ErB9Rvdee/gqET GfS6FtV8SXIGlSKQ+0c0q4BVxM3LttghMmcZXwRrCNeg8juuGHOZFIVzxAl8ZKVCOL// SdwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679652161; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hqniG2RTuzYc41TgGVo3CFmOEDPj8x/ry7qdxr2ig3U=; b=5G4l68lKQUphbo0UflAq2yAozno8WRG8PKlx1rq10BAoelzbY1sU4RWrCuCmK8rPAf fLRdNsKFHRx9xV2q8pUStjdCxGFGjYaDseorhHCyZf3YtCH36NYmcr1/x8TpxWV6MzNw bhlTeHvuq6R89Na9aknoTwLVe0xBhGsfO79Nglj3dzGF/KxuAm909vea/Vmc/iRhk7KW ka1C4KZckelmbgjFISHmDnqpgwsVcnB0ORkbGuyQm900pnb6GMiXpE510RaDuHRCE7C4 82pD+zeo8E462xxSYUp/zyswdAHJRVavuxe4CuT8DRVYsB/facn9Vay3gXOEoAK7ISME DdDQ== X-Gm-Message-State: AAQBX9eyGoXZkJaUgt1K3ny6dQiSb86evcibE/WrgwByBZAmifZr79Rq 1F+Jwf7RBaTtDa/zv3Y9J2wHlg== X-Google-Smtp-Source: AKy350afxW/MzPpBo1E2U1b5voWjHTIIgFJ0cAMVXcl7lU1aJbGr3gBYCSMuQrZgHHbXj2qJBotQ7w== X-Received: by 2002:a19:ae02:0:b0:4ea:129c:528 with SMTP id f2-20020a19ae02000000b004ea129c0528mr653408lfc.56.1679652161179; Fri, 24 Mar 2023 03:02:41 -0700 (PDT) Received: from localhost.localdomain (bl20-118-143.dsl.telepac.pt. [2.81.118.143]) by smtp.googlemail.com with ESMTPSA id q23-20020a19a417000000b004d865c781eesm3282268lfc.24.2023.03.24.03.02.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Mar 2023 03:02:40 -0700 (PDT) From: =?utf-8?q?Nuno_Gon=C3=A7alves?= To: =?utf-8?b?QmrDtnJuIFTDtnBlbA==?= , Magnus Karlsson , Maciej Fijalkowski , Jonathan Lemon , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Christian Brauner , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend Cc: =?utf-8?q?Nuno_Gon=C3=A7alves?= , netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH bpf-next V4] xsk: allow remap of fill and/or completion rings Date: Fri, 24 Mar 2023 10:02:22 +0000 Message-Id: <20230324100222.13434-1-nunog@fr24.com> X-Mailer: git-send-email 2.40.0 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org X-Patchwork-Delegate: bpf@iogearbox.net The remap of fill and completion rings was frowned upon as they control the usage of UMEM which does not support concurrent use. At the same time this would disallow the remap of these rings into another process. A possible use case is that the user wants to transfer the socket/ UMEM ownership to another process (via SYS_pidfd_getfd) and so would need to also remap these rings. This will have no impact on current usages and just relaxes the remap limitation. Signed-off-by: Nuno Gonçalves Reviewed-by: Maciej Fijalkowski Acked-by: Magnus Karlsson --- V3 -> V4: Remove undesired format changes V2 -> V3: Call READ_ONCE for each variable and not for the ternary operator V1 -> V2: Format and comment changes net/xdp/xsk.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) -- 2.40.0 diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c index 2ac58b282b5eb..cc1e7f15fa731 100644 --- a/net/xdp/xsk.c +++ b/net/xdp/xsk.c @@ -1301,9 +1301,10 @@ static int xsk_mmap(struct file *file, struct socket *sock, loff_t offset = (loff_t)vma->vm_pgoff << PAGE_SHIFT; unsigned long size = vma->vm_end - vma->vm_start; struct xdp_sock *xs = xdp_sk(sock->sk); + int state = READ_ONCE(xs->state); struct xsk_queue *q = NULL; - if (READ_ONCE(xs->state) != XSK_READY) + if (state != XSK_READY && state != XSK_BOUND) return -EBUSY; if (offset == XDP_PGOFF_RX_RING) { @@ -1314,9 +1315,11 @@ static int xsk_mmap(struct file *file, struct socket *sock, /* Matches the smp_wmb() in XDP_UMEM_REG */ smp_rmb(); if (offset == XDP_UMEM_PGOFF_FILL_RING) - q = READ_ONCE(xs->fq_tmp); + q = state == XSK_READY ? READ_ONCE(xs->fq_tmp) : + READ_ONCE(xs->pool->fq); else if (offset == XDP_UMEM_PGOFF_COMPLETION_RING) - q = READ_ONCE(xs->cq_tmp); + q = state == XSK_READY ? READ_ONCE(xs->cq_tmp) : + READ_ONCE(xs->pool->cq); } if (!q)