From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f198.google.com (mail-dy1-f198.google.com [74.125.82.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D4EF84A8A1B for ; Fri, 9 Oct 2026 23:56:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.198 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791590183; cv=none; b=E7WZlsU/O7NazMwM+l3tWcm2viltVa2tftyDKW3Sf6FxAOgI0L4nYsNJA8r+bUpHq+5H8gXQJCoXIcJwu4trMr6BPSqmadRxBeUC4nPb5Z10+Y4F8VfrKb2JZzRVThru+GRFlWbs5HbjBnsLxKQDXCqbxphoTihz5pNmE+UaX+E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791590183; c=relaxed/simple; bh=HJjEutuWqmXwhqtRudU4Sn1MORYvdSadpDAAbYlfYkA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=OcCtqvbMPfenEepnym6oDoPQ7hKAzpL8Qt99a7ilplWf4dGhVEFwfODrclYiwURkhX7R2/YDIl6AVY+7Zg63J11sYDKvB9hh9QtsjYl0WZC8a2rA9PJFzD8bdUyhEYS6bmXQRbwJ1cb4mAUdWcjLOQksPYGK7rfOjY0OAdR+FsM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--almasrymina.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=dNmkwgJa; arc=none smtp.client-ip=74.125.82.198 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--almasrymina.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="dNmkwgJa" Received: by mail-dy1-f198.google.com with SMTP id 5a478bee46e88-30bcb065bfdso490453eec.0 for ; Fri, 09 Oct 2026 16:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1791590181; x=1792194981; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=5XaFCfc03yewNn7fG/JQ4ITn5aqHWRNRq1VQ5fsL4bc=; b=dNmkwgJaOAI3I7IqA6yrgLVhuOpKVxymOSmaW41dXnQkHu/BV3mTV5AB4F3xXu047D X6PK5khqhflvkQlAlrF2XVmsvFJf7DM5xRZbTqwTUwIfSP7LXKgRFXHxScdwh6aBWL/p k72lT8bUUPVvpCj/VBgJfGJ63ooXOf6VzgrNFm1N0vGkdNb+YU4qPqsz1dNRUFR3yD1s 21a8l4j+c7A+GjeVL817QXX8x3IfLcY2/DoZ8sRq6DG3trOYo9NwZlpHcVDclgRy5wkG t2J9JNI/ZbwW081xCy2Z2YMuiinqcQlhtJO00pdCrdwQ9bi8FHwCxSg6eB+NflcJldHH 4aqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791590181; x=1792194981; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=5XaFCfc03yewNn7fG/JQ4ITn5aqHWRNRq1VQ5fsL4bc=; b=JiFTCwGuJyl7fi5EQtXRhhnoTLMuBLe7j2N/L7OiT5DYiTtSsTN4S+xnYVpSO14Rto sm7xgAHVu6wHzK2rAqtvYlSHmmCE9Kg5149TwZDyvayo4b/lnDKg+gv/c/XZyKXrC+/T JR4NyHKGSu7vnzGdG/SxP39c6+Hejgeck3koKDvAOTFOhYJ6fOAvTzsAyNYww8NWQZ6P ZLp6d420isvajJ1yvHBEJMYuJiyRNn3apaYZqy4qjPWvtTNTkAYpJbt0CkgSmQrl/ZKL TEbymue5vC8YSamXF4ziZG7gzwAXfemZX7pJJ1/LtGYFXst0//PzZ/YytvGPn5wyIvXE YRKQ== X-Forwarded-Encrypted: i=1; AKwUvBzP67BpFBkOWGmFG00ruY/Pj+a0Ta//uOPFOMmzEc2w1MEjPgQQ20qCmzq5Z63VTqQDYJCliZT3ec9R00s=@vger.kernel.org X-Gm-Message-State: AFq9FYKtb6ud2YjPhnv93AthPA7zGzljEQiRyFpp/kE8S42B8YkfccEZ LO0f+kKMAhe7YrilJZypiS0O5XfWs/XwUEcm9lTl8bHb/aJl/fbMV9hR5Saqmpa4VYOjl81Z83h xKP7PteZEYVRXrMgUCTzBHn2a1w== X-Received: from dyz18.prod.google.com ([2002:a05:693c:4092:b0:34d:46b2:7513]) (user=almasrymina job=prod-delivery.src-stubby-dispatcher) by 2002:a05:7300:f582:b0:353:5ae1:b0f5 with SMTP id 5a478bee46e88-3537e101bf0mr4196027eec.26.1791590180476; Fri, 09 Oct 2026 16:56:20 -0700 (PDT) Date: Fri, 9 Oct 2026 23:56:19 +0000 In-Reply-To: <20261008132815.654147-10-tariqt@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20261008132815.654147-1-tariqt@nvidia.com> <20261008132815.654147-10-tariqt@nvidia.com> X-Mailer: git-send-email 2.56.0.385.gd3acb90ef8-goog Message-ID: <20261009235619.3826575-1-almasrymina@google.com> Subject: Re: [PATCH net-next 09/10] net: devmem: add netdev_has_dmabuf_binding() helper From: Mina Almasry To: Tariq Toukan Cc: Mina Almasry , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , netdev@vger.kernel.org, Paolo Abeni , Bobby Eshleman , Byungchul Park , Carolina Jubran , Cosmin Ratiu , Dragos Tatulea , Gal Pressman , Jacob Keller , Kees Cook , Leon Romanovsky , open list , linux-rdma@vger.kernel.org, Mark Bloch , Matt Fleming , Nikolay Aleksandrov , Saeed Mahameed , Shivaji Kant , Simon Horman , Stanislav Fomichev , Stanislav Fomichev , William Tu , Yue Haibing , Bobby Eshleman Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 8, 2026 at 6:28 AM Tariq Toukan wrote: > From: Dragos Tatulea > > A binding can outlive its xarray slot: it can still be referenced by > in-flight TX skbs, whose DMA mappings are only valid for the device the > dmabuf was attached to. Reporting such a binding as gone would let a > driver swap the DMA device out from under those skbs. For this reason, > track bindings for their whole lifetime on a new list. (Note: LLM-assisted review comment below.) Two suggestions on the core design here: 1. Add a synchronous DMA detach helper (e.g. netdev_unbind_dmabuf_dma_dev(d= ev, dma_dev)) alongside netdev_has_dmabuf_binding() so patch 08/10 can clean= ly tear down active bindings on MLX5_DATA_DIRECT_UNBIND: - Separate DMA mapping lifetime (ends synchronously when queues stop and dev/vdev/dma_dev goes away) from CPU net_iov lifetime (ends in __net_devmem_dmabuf_binding_free() when binding->ref hits 0). - For bindings matching (dev, binding->attachment->dev =3D=3D dma_dev), = close bound RX queues (netif_mp_close_rxq()), erase binding->id from net_devmem_dmabuf_bindings, clear WRITE_ONCE(binding->dev, NULL) / WRITE_ONCE(binding->vdev, NULL), call synchronize_net(), and unmap/det= ach binding->sgt and binding->attachment synchronously (setting them to NU= LL so __net_devmem_dmabuf_binding_free() skips them later). - Note: core devmem also has a pre-existing bug on physical/virtual NETDEV_UNREGISTER where mp_dmabuf_devmem_uninstall() and TX bindings l= eave dma_buf mapped past pci_driver->remove() and TX bindings leave binding->dev / binding->vdev dangling; sharing a single core detach helper solves both cleanly with zero new fields in struct net_devmem_dmabuf_binding. 2. Once detach (and net_devmem_unbind_dmabuf() on TX unbind) clears WRITE_ONCE(binding->dev, NULL), runs synchronize_net(), and unmaps binding->sgt synchronously, any binding already erased from net_devmem_dmabuf_bindings is already DMA-unmapped and rejected by validate_xmit_unreadable_skb() (READ_ONCE(binding->dev) !=3D dev). That eliminates the need for net_devmem_live_bindings_lock / live_list =E2=80= =94 iterating net_devmem_dmabuf_bindings under netdev_lock(dev) suffices for both netdev_has_dmabuf_binding() and netdev_unbind_dmabuf_dma_dev(). --=20 Thanks, Mina