On Thu, 29 Aug 2024 22:41:17 -0700 Mina Almasry wrote:
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.
FWIW it's best to keep the error path a mirror image of the success
path, so I'd add a new label "err_relock" or something. But..
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.
..indeed, best to keep it atomic. So let's hold rtnl_lock longer.
genlmsg_reply() shouldn't block, AFAIU.
BTW CI is quite behind but Yunsheng ignored it and reposted his
"refactor" which is going to take us another 10 hours back,
so whatever, just post v24 when you're ready...