[RFC] xen/pvcalls: possible bind/disconnect mapping lifetime race

[Sang-Hoon Choi]

Hi,

I would like to report a possible race between pvcalls_back_bind() and
backend_disconnect(), found during source review.

The source reviewed is mainline commit
5dd1818b15d98d4a20806cd00b1b40320b06004f.

pvcalls_back_bind() inserts a new sockpass_mapping into
socketpass_mappings under socket_lock, then drops that lock before
installing the socket callbacks:

    radix_tree_insert(..., map);
    up(&fedata->socket_lock);
    write_lock_bh(&map->sock->sk->sk_callback_lock);
    map->saved_data_ready = map->sock->sk->sk_data_ready;
    map->sock->sk->sk_user_data = map;
    map->sock->sk->sk_data_ready = pvcalls_pass_sk_data_ready;

backend_disconnect() takes socket_lock, removes passive mappings, and
calls pvcalls_back_release_passive(). That function restores the socket
callback, releases the socket, destroys the workqueue, and frees the
mapping. The request IRQ is unbound only after this cleanup.

If disconnect overlaps the threaded request handler, this appears to
allow the mapping to be freed between insertion and callback setup:

    bind handler                    disconnect
    ------------                    ----------
    insert map
    drop socket_lock
                                    take socket_lock
                                    remove and release map
    access map->sock

A draft change holds socket_lock through callback setup. This preserves
the socket_lock -> sk_callback_lock order used during disconnect and
addresses the interval above. It is not a complete teardown fix: an
in-flight handler could still insert a mapping after disconnect has
finished walking the tree. Quiescing the request IRQ before freeing
mappings may be the better approach, but needs a separate teardown and
deadlock review.

The narrow draft was compile-checked as pvcalls-back.o with W=1 in an
x86 allmodconfig build at the commit above and passed checkpatch. It has
not been tested in a Xen frontend/backend setup. There is no runtime
reproducer or sanitizer trace, and no security impact has been established.
XEN_PVCALLS_BACKEND is marked experimental in Kconfig.

Is there synchronization outside these functions that prevents the
request handler from overlapping backend_disconnect()?

Reported-by: Changyul Lee <lcy8047@xxxxxxxxx>
Assisted-by: LLM

Thanks,
Sang-Hoon Choi