Thread (26 messages) 26 messages, 4 authors, 2024-08-30

Re: [PATCH net-next v23 03/13] netdev: support binding dma-buf to netdevice

From: Mina Almasry <hidden>
Date: 2024-08-30 05:41:32
Also in: bpf, dri-devel, linux-alpha, linux-arch, linux-doc, linux-kselftest, linux-media, linux-mips, linux-trace-kernel, lkml, sparclinux

On Thu, Aug 29, 2024 at 2:24 PM Vadim Fedorenko
[off-list ref] wrote:
On 29/08/2024 22:08, Jakub Kicinski wrote:
quoted
On Thu, 29 Aug 2024 06:01:16 +0000 Mina Almasry wrote:
quoted
+    err = genlmsg_reply(rsp, info);
+    if (err)
+            goto err_unbind;
+
     return 0;
+
+err_unbind:
rtnl_lock()
There are 2 places with goto err_unbind, and one is under the lock,
additional label (or rearrange of the last check) is needed..
Thank you, I think the right fix here is to reacquire rtnl_lock before
the `goto err_unbind;`, since err_unbind expects rtnl to be locked at
this point.

This could introduce a weird edge case where we drop rtnl_lock, then
find out genlmsg_reply failed, then reacquire rtnl_lock to do the
cleanup. I can't think of anything that would horribly break if we do
that, but I may be missing something. In theory we could race with a
dmabuf unbind call happening in parallel.

If we can't reacquire rtnl_lock to do the cleanup, I think I need to
revert back to doing genlmsg_reply inside of rtnl_lock, and dropping
the lock before we return from the function.

-- 
Thanks,
Mina
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help