From: Stanislav Fomichev <stfomichev@gmail.com>
To: Mina Almasry <almasrymina@google.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, virtualization@lists.linux.dev,
kvm@vger.kernel.org, linux-kselftest@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Simon Horman" <horms@kernel.org>,
"Donald Hunter" <donald.hunter@gmail.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
"David Ahern" <dsahern@kernel.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Stefano Garzarella" <sgarzare@redhat.com>,
"Shuah Khan" <shuah@kernel.org>,
"Kaiyuan Zhang" <kaiyuanz@google.com>,
"Pavel Begunkov" <asml.silence@gmail.com>,
"Willem de Bruijn" <willemb@google.com>,
"Samiullah Khawaja" <skhawaja@google.com>,
"Stanislav Fomichev" <sdf@fomichev.me>,
"Joe Damato" <jdamato@fastly.com>,
dw@davidwei.uk
Subject: Re: [PATCH RFC net-next v1 3/5] net: add get_netmem/put_netmem support
Date: Thu, 26 Dec 2024 11:07:01 -0800 [thread overview]
Message-ID: <Z22pVRcr-B624UcG@mini-arch> (raw)
In-Reply-To: <20241221004236.2629280-4-almasrymina@google.com>
On 12/21, Mina Almasry wrote:
> Currently net_iovs support only pp ref counts, and do not support a
> page ref equivalent.
>
> This is fine for the RX path as net_iovs are used exclusively with the
> pp and only pp refcounting is needed there. The TX path however does not
> use pp ref counts, thus, support for get_page/put_page equivalent is
> needed for netmem.
>
> Support get_netmem/put_netmem. Check the type of the netmem before
> passing it to page or net_iov specific code to obtain a page ref
> equivalent.
>
> For dmabuf net_iovs, we obtain a ref on the underlying binding. This
> ensures the entire binding doesn't disappear until all the net_iovs have
> been put_netmem'ed. We do not need to track the refcount of individual
> dmabuf net_iovs as we don't allocate/free them from a pool similar to
> what the buddy allocator does for pages.
>
> This code is written to be extensible by other net_iov implementers.
> get_netmem/put_netmem will check the type of the netmem and route it to
> the correct helper:
>
> pages -> [get|put]_page()
> dmabuf net_iovs -> net_devmem_[get|put]_net_iov()
> new net_iovs -> new helpers
>
> Signed-off-by: Mina Almasry <almasrymina@google.com>
>
> ---
> include/linux/skbuff_ref.h | 4 ++--
> include/net/netmem.h | 3 +++
> net/core/devmem.c | 10 ++++++++++
> net/core/devmem.h | 11 +++++++++++
> net/core/skbuff.c | 30 ++++++++++++++++++++++++++++++
> 5 files changed, 56 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/skbuff_ref.h b/include/linux/skbuff_ref.h
> index 0f3c58007488..9e49372ef1a0 100644
> --- a/include/linux/skbuff_ref.h
> +++ b/include/linux/skbuff_ref.h
> @@ -17,7 +17,7 @@
> */
> static inline void __skb_frag_ref(skb_frag_t *frag)
> {
> - get_page(skb_frag_page(frag));
> + get_netmem(skb_frag_netmem(frag));
> }
>
> /**
> @@ -40,7 +40,7 @@ static inline void skb_page_unref(netmem_ref netmem, bool recycle)
> if (recycle && napi_pp_put_page(netmem))
> return;
> #endif
[..]
> - put_page(netmem_to_page(netmem));
> + put_netmem(netmem);
I moved the release operation onto a workqueue in my series [1] to avoid
calling dmabuf detach (which can sleep) from the socket close path
(which is called with bh disabled). You should probably do something similar,
see the trace attached below.
1: https://github.com/fomichev/linux/commit/3b3ad4f36771a376c204727e5a167c4993d4c65a#diff-3c58b866674b2f9beb5ac7349f81566e4df595c25c647710203549589d450f2dR436
(the condition to trigger that is to have an skb in the write queue
and call close from the userspace)
[ 1.548495] BUG: sleeping function called from invalid context at drivers/dma-buf/dma-buf.c:1255
[ 1.548741] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 149, name: ncdevmem
[ 1.548926] preempt_count: 201, expected: 0
[ 1.549026] RCU nest depth: 0, expected: 0
[ 1.549197]
[ 1.549237] =============================
[ 1.549331] [ BUG: Invalid wait context ]
[ 1.549425] 6.13.0-rc3-00770-gbc9ef9606dc9-dirty #15 Tainted: G W
[ 1.549609] -----------------------------
[ 1.549704] ncdevmem/149 is trying to lock:
[ 1.549801] ffff8880066701c0 (reservation_ww_class_mutex){+.+.}-{4:4}, at: dma_buf_unmap_attachment_unlocked+0x4b/0x90
[ 1.550051] other info that might help us debug this:
[ 1.550167] context-{5:5}
[ 1.550229] 3 locks held by ncdevmem/149:
[ 1.550322] #0: ffff888005730208 (&sb->s_type->i_mutex_key#11){+.+.}-{4:4}, at: sock_close+0x40/0xf0
[ 1.550530] #1: ffff88800b148f98 (sk_lock-AF_INET6){+.+.}-{0:0}, at: tcp_close+0x19/0x80
[ 1.550731] #2: ffff88800b148f18 (slock-AF_INET6){+.-.}-{3:3}, at: __tcp_close+0x185/0x4b0
[ 1.550921] stack backtrace:
[ 1.550990] CPU: 0 UID: 0 PID: 149 Comm: ncdevmem Tainted: G W 6.13.0-rc3-00770-gbc9ef9606dc9-dirty #15
[ 1.551233] Tainted: [W]=WARN
[ 1.551304] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
[ 1.551518] Call Trace:
[ 1.551584] <TASK>
[ 1.551636] dump_stack_lvl+0x86/0xc0
[ 1.551723] __lock_acquire+0xb0f/0xc30
[ 1.551814] ? dma_buf_unmap_attachment_unlocked+0x4b/0x90
[ 1.551941] lock_acquire+0xf1/0x2a0
[ 1.552026] ? dma_buf_unmap_attachment_unlocked+0x4b/0x90
[ 1.552152] ? dma_buf_unmap_attachment_unlocked+0x4b/0x90
[ 1.552281] ? dma_buf_unmap_attachment_unlocked+0x4b/0x90
[ 1.552408] __ww_mutex_lock+0x121/0x1060
[ 1.552503] ? dma_buf_unmap_attachment_unlocked+0x4b/0x90
[ 1.552648] ww_mutex_lock+0x3d/0xa0
[ 1.552733] dma_buf_unmap_attachment_unlocked+0x4b/0x90
[ 1.552857] __net_devmem_dmabuf_binding_free+0x56/0xb0
[ 1.552979] skb_release_data+0x120/0x1f0
[ 1.553074] __kfree_skb+0x29/0xa0
[ 1.553156] tcp_write_queue_purge+0x41/0x310
[ 1.553259] tcp_v4_destroy_sock+0x127/0x320
[ 1.553363] ? __tcp_close+0x169/0x4b0
[ 1.553452] inet_csk_destroy_sock+0x53/0x130
[ 1.553560] __tcp_close+0x421/0x4b0
[ 1.553646] tcp_close+0x24/0x80
[ 1.553724] inet_release+0x5d/0x90
[ 1.553806] sock_close+0x4a/0xf0
[ 1.553886] __fput+0x9c/0x2b0
[ 1.553960] task_work_run+0x89/0xc0
[ 1.554046] do_exit+0x27f/0x980
[ 1.554125] do_group_exit+0xa4/0xb0
[ 1.554211] __x64_sys_exit_group+0x17/0x20
[ 1.554309] x64_sys_call+0x21a0/0x21a0
[ 1.554400] do_syscall_64+0xec/0x1d0
[ 1.554487] ? exc_page_fault+0x8a/0xf0
[ 1.554585] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 1.554703] RIP: 0033:0x7f2f8a27abcd
next prev parent reply other threads:[~2024-12-26 19:07 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-21 0:42 [PATCH RFC net-next v1 0/5] Device memory TCP TX Mina Almasry
2024-12-21 0:42 ` [PATCH RFC net-next v1 1/5] net: add devmem TCP TX documentation Mina Almasry
2024-12-21 4:56 ` Stanislav Fomichev
2025-01-27 22:45 ` Mina Almasry
2025-01-28 3:51 ` Stanislav Fomichev
2024-12-21 0:42 ` [PATCH RFC net-next v1 2/5] selftests: ncdevmem: Implement devmem TCP TX Mina Almasry
2024-12-21 4:57 ` Stanislav Fomichev
2024-12-26 21:24 ` Willem de Bruijn
2024-12-21 0:42 ` [PATCH RFC net-next v1 3/5] net: add get_netmem/put_netmem support Mina Almasry
2024-12-26 19:07 ` Stanislav Fomichev [this message]
2025-01-27 22:47 ` Mina Almasry
2024-12-21 0:42 ` [PATCH RFC net-next v1 4/5] net: devmem TCP tx netlink api Mina Almasry
2024-12-21 0:42 ` [PATCH RFC net-next v1 5/5] net: devmem: Implement TX path Mina Almasry
2024-12-21 5:09 ` Stanislav Fomichev
2024-12-26 19:10 ` Stanislav Fomichev
2025-01-27 22:52 ` Mina Almasry
2024-12-26 21:52 ` Willem de Bruijn
2025-01-28 0:06 ` Mina Almasry
2025-01-28 14:49 ` Willem de Bruijn
2025-02-05 12:41 ` Pavel Begunkov
2025-02-05 20:22 ` Mina Almasry
2025-02-05 22:16 ` Pavel Begunkov
2025-02-05 22:22 ` Pavel Begunkov
2025-02-10 21:14 ` Mina Almasry
2024-12-28 19:28 ` David Ahern
2024-12-21 4:53 ` [PATCH RFC net-next v1 0/5] Device memory TCP TX Stanislav Fomichev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z22pVRcr-B624UcG@mini-arch \
--to=stfomichev@gmail.com \
--cc=almasrymina@google.com \
--cc=andrew+netdev@lunn.ch \
--cc=asml.silence@gmail.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=dsahern@kernel.org \
--cc=dw@davidwei.uk \
--cc=edumazet@google.com \
--cc=eperezma@redhat.com \
--cc=horms@kernel.org \
--cc=jasowang@redhat.com \
--cc=jdamato@fastly.com \
--cc=kaiyuanz@google.com \
--cc=kuba@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=sgarzare@redhat.com \
--cc=shuah@kernel.org \
--cc=skhawaja@google.com \
--cc=stefanha@redhat.com \
--cc=virtualization@lists.linux.dev \
--cc=willemb@google.com \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).