From nobody Sun Feb 8 02:42:09 2026 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 65901C6FD20 for ; Fri, 24 Mar 2023 10:02:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231311AbjCXKCw (ORCPT ); Fri, 24 Mar 2023 06:02:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57844 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231358AbjCXKCr (ORCPT ); Fri, 24 Mar 2023 06:02:47 -0400 Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EB9EA2367E for ; Fri, 24 Mar 2023 03:02:42 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id j11so1449724lfg.13 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=hsCeiTupodOzzmzXCrUtn0+VUEOHx0s5MgQEQrfH4ZtsvJXJ3dyBlHwegvAUtR+Hxm zhDoaxxho+XjrVQgao4XbDvZzudQIvUs/fpTow28sTkXjzapAmi5nMjZNRz0hKE4xoas J3vuRcAHREbw8r7dQX8A4adRVa8/gExrBvExIqxCtq7yVRZOv+4MU7e2Yuk8V/jKNCRF GDGSJtCHL7ce0b0fSlcHTbPs/MRuiUH5fIiNiUKU3fU16lbQOaYGL7J6zCow2xPJAMh8 SJbUzPrx/3/UI2bhyoHYQ1BnnMMKo119cu9xp6oa+szJ9va808ohDPRaYb7Yx4D0bklZ Wypg== X-Gm-Message-State: AAQBX9fTlTwuEM6VQF2RA1he0XURIttjWWcP5jCwnrGPMl1+4s4Y3zT6 j4psVquIJO/wLKugqzLJqyrTww== 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=20Gon=C3=A7alves?= To: =?UTF-8?q?Bj=C3=B6rn=20T=C3=B6pel?= , 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=20Gon=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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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=C3=A7alves Acked-by: Magnus Karlsson Reviewed-by: Maciej Fijalkowski --- 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(-) 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 =3D (loff_t)vma->vm_pgoff << PAGE_SHIFT; unsigned long size =3D vma->vm_end - vma->vm_start; struct xdp_sock *xs =3D xdp_sk(sock->sk); + int state =3D READ_ONCE(xs->state); struct xsk_queue *q =3D NULL; - if (READ_ONCE(xs->state) !=3D XSK_READY) + if (state !=3D XSK_READY && state !=3D XSK_BOUND) return -EBUSY; if (offset =3D=3D 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 =3D=3D XDP_UMEM_PGOFF_FILL_RING) - q =3D READ_ONCE(xs->fq_tmp); + q =3D state =3D=3D XSK_READY ? READ_ONCE(xs->fq_tmp) : + READ_ONCE(xs->pool->fq); else if (offset =3D=3D XDP_UMEM_PGOFF_COMPLETION_RING) - q =3D READ_ONCE(xs->cq_tmp); + q =3D state =3D=3D XSK_READY ? READ_ONCE(xs->cq_tmp) : + READ_ONCE(xs->pool->cq); } if (!q) -- 2.40.0