`rmmod fastrpc` hangs

[basak-qcom]

FastRPC version

v1.0.2

DSP firmware version

ADSP.HT.5.5.c8-00217-KODIAK-1 from hdb 20260110

SoC and device name

RB3gen2 with vision kit

Kernel version

v7.0.0-rc2

What happened?

rmmod fastrpc hangs. To reproduce, I'm using RB3gen2 with the image from Weekly mainline linux build · qualcomm-linux/qcom-deb-images@187202e running linux v7.0.0-rc2, configuring wifi and installing openssh-server, then over ssh masking and stopping the adsprpcd and cdsprpcd services, then rmmod fastrpc. From a kernel point of view, note that the daemons were started and then stopped. I haven't checked if this is required to reproduce.

I get similar behaviour with 6.18.9+deb13-arm64 from trixie-backports, but I suppose the focus should be to get this working on mainline.

The reason is that I wanted to test things like the udev rules and systemd services, and the easiest way to do that without constantly rebooting is to check behaviour on a module reload.

Steps to reproduce

As above.

Relevant log output

Nothing in dmesg at the time of the hang.

[quic-anane]

[<0>] device_del+0x40/0x40c
[<0>] device_unregister+0x14/0x34
[<0>] rpmsg_unregister_device+0x28/0x4c
[<0>] qcom_glink_remove_rpmsg_device+0x6c/0xbc
[<0>] qcom_glink_destroy_ept+0x3c/0x60
[<0>] rpmsg_dev_remove+0x50/0x60
[<0>] device_remove+0x4c/0x80
[<0>] device_release_driver_internal+0x1c8/0x220
[<0>] driver_detach+0x4c/0x94
[<0>] bus_remove_driver+0x68/0xb8
[<0>] driver_unregister+0x30/0x60
[<0>] unregister_rpmsg_driver+0x10/0x20
[<0>] fastrpc_exit+0x28/0x40 [fastrpc]
[<0>] __arm64_sys_delete_module+0x1bc/0x2a0
[<0>] invoke_syscall.constprop.0+0x40/0xf0
[<0>] el0_svc_common.constprop.0+0x38/0xd8
[<0>] do_el0_svc+0x1c/0x28
[<0>] el0_svc+0x34/0x104
[<0>] el0t_64_sync_handler+0xa0/0xe4
[<0>] el0t_64_sync+0x19c/0x1a0

The hang is happening in mproc layer during rpmsg device release. @quic-vishsant to provide further analysis from mproc perspective

[quic-vishsant]

The is due to a recent patch merged in upstream from another team for solving a different issue : ([PATCH 1/2] rpmsg: glink_native: fix rpmsg device leak - srinivas.kandagatla). This patch is causing a deadlock on local rpmsg unregister path.

root@qcs9100-ride-sx:/# cat /proc/1701/stack
[<0>] device_del+0x40/0x40c # tries to acquire the same device_lock(dev) again which is causing deadlock.
[<0>] device_unregister+0x14/0x34
[<0>] rpmsg_unregister_device+0x28/0x4c
[<0>] qcom_glink_remove_rpmsg_device+0x6c/0xbc # newly introduced api causing the problem
[<0>] qcom_glink_destroy_ept+0x3c/0x60
[<0>] rpmsg_dev_remove+0x50/0x60
[<0>] device_remove+0x4c/0x80
[<0>] device_release_driver_internal+0x1c8/0x220 # device_lock(dev) acquired for device (fastrpcglink-apps-dsp.-1.-1)
[<0>] driver_detach+0x4c/0x94
[<0>] bus_remove_driver+0x68/0xb8
[<0>] driver_unregister+0x30/0x60
[<0>] unregister_rpmsg_driver+0x10/0x20
[<0>] fastrpc_exit+0x28/0x40 [fastrpc]
[<0>] __arm64_sys_delete_module+0x1bc/0x2a0
[<0>] invoke_syscall.constprop.0+0x40/0xf0
[<0>] el0_svc_common.constprop.0+0x38/0xd8
[<0>] do_el0_svc+0x1c/0x28
[<0>] el0_svc+0x34/0x104
[<0>] el0t_64_sync_handler+0xa0/0xe4
[<0>] el0t_64_sync+0x19c/0x1a0

When destroy_ept is called from the driver detach path (rpmsg_dev_remove), the driver core is already tearing down the rpdev and there is nothing for glink to do here.

Checking with the original owner who raised the patch to understand the real problem. Based on that will raise patch to fix both issues at once.