summaryrefslogtreecommitdiffstats
path: root/kernel
diff options
context:
space:
mode:
authorArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-09 02:21:28 -0400
committerArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-09 02:21:28 -0400
commitbcdeb989eb0ce32248b8b8db750ed1de361cf5c2 (patch)
tree076ad8654d237dbe6f8e1c5ba111cbfaf176b9af /kernel
parent14fbfebd12216b5a574602a4703de5ab69a079c7 (diff)
downloadopen-iov-bcdeb989eb0ce32248b8b8db750ed1de361cf5c2.tar.gz
open-iov-bcdeb989eb0ce32248b8b8db750ed1de361cf5c2.zip
vgsp-sema: flush host-injected pins with the session (ISSUE-0002)
The pin-stream tool follows the live client's pid, but its injected entries survived the session flush. The next client reuses the same VAs with new PAs, so stale injections resolved it through the previous client's pages - the second-client exit hang. The 10/10 gate never ran the stream (green); the handover harness does, which is why r3-r10 saw the hang. The queue is drained on svc_thread (svc_handle_map_add), the same thread as this flush, so the clear cannot race it.
Diffstat (limited to 'kernel')
-rw-r--r--kernel/gsp_sema_service.c10
1 files changed, 10 insertions, 0 deletions
diff --git a/kernel/gsp_sema_service.c b/kernel/gsp_sema_service.c
index 9e3b14c..e6459f3 100644
--- a/kernel/gsp_sema_service.c
+++ b/kernel/gsp_sema_service.c
@@ -6377,6 +6377,16 @@ static void svc_session_flush(void)
*/
memset(svc.pin, 0, sizeof(svc.pin));
svc.pin_n = 0;
+ /*
+ * Host-injected pins are session-scoped too: the streaming tool
+ * follows the live client's pid, so at session end its entries are
+ * stale. Leaving them let the next client resolve through the
+ * previous client's pages (same VAs, new PAs) - the second-client
+ * exit hang. The injection queue itself is drained on this thread
+ * (svc_handle_map_add), so this clear cannot race it.
+ */
+ memset(svc.ipin, 0, sizeof(svc.ipin));
+ svc.ipin_n = 0;
memset(svc_cnt_der, 0, sizeof(svc_cnt_der));
svc_cnt_der_n = 0;
memset(svc_hot, 0, sizeof(svc_hot));