From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vasileios Almpanis Date: Tue, 25 Aug 2026 16:19:50 +0000 Subject: [Devel] [PATCH VZ10 v3 0/4] connector: do not lose exit events for in-CT listeners Message-ID: <20260825-connectors-v3-0-7b26773876a0@virtuozzo.com> List-Id: The proc connector reports the exit event after exit_notify(), so the parent may already have reaped the exiting task. release_task() -> exit_ve_namespace() then resets tsk->task_ve to ve0, and if that wins the race the event is delivered to the host listeners only. A listener inside the container never sees the exit event. LTP catches this as the flaky cn_pec exit-test failure causing the test to hang for as long as 8 hours on GCOV kernels. Patch 4 fixes this by pinning the task's VE for the exit notification before exit_notify(). This means the delivery path can now run against a VE whose last task is already reaped, i.e. concurrently with the per-VE connector teardown, which was impossible before. Patches 1-3 prepare for that: annotate ve->cn with __rcu, free the per-VE connector state only after an RCU grace period, and deliver per-VE events under rcu_read_lock(). Testing: KASAN, PROVE_LOCKING/PROVE_RCU, DEBUG_OBJECTS, kmemleak=on; HCI VM with one container): - LTP cn_pec inside a CT: unpatched kernel loses exit events in 3 of 10 runs (-n 50); patched kernel passes 30 of 30 runs. - Teardown stress: 15 cycles of an active in-CT pec_listener plus a 200-process exit storm with vzctl stop/start while events are in flight: no KASAN/lockdep/RCU splats, kmemleak scans report 0 unreferenced objects. https://virtuozzo.atlassian.net/browse/VSTOR-140421 --- Changes in v3: - Patch 2: also make the netlink receive path safe against the VE stop. cn_call_callback() can be reached by a host task in the CT netns (e.g. nsenter) after ve->cn is cleared but before the kernel socket is released in cn_fini_ve(); look up the callback device and walk the queue under rcu_read_lock() and bail out on NULL (Konstantin). - Patch 2: wait for an RCU grace period in the cn_init_ve() error path too before freeing ve->cn, since it is published early with rcu_assign_pointer(); symmetric to cn_proc_fini_ve(). This also covers the early-publish concern raised on patch 1. - Link to v2: https://lists.openvz.org/pipermail/devel/2026-August/084616.html Changes in v2: - Turned the single patch into a series: with the exit event now delivered for a possibly already-reaped task, the per-VE delivery path can race with the connector teardown in cn_fini_ve(). New patches 1-3 make that safe: annotate ve->cn with __rcu, free the per-VE connector state only after an RCU grace period, and run the delivery under rcu_read_lock(). - cn_proc.h: forward-declare struct ve_struct instead of including linux/ve.h. - Link to v1: https://lists.openvz.org/pipermail/devel/2026-August/084581.html --- Vasileios Almpanis (4): connector: annotate ve->cn with __rcu connector: free the per-VE connector state after an RCU grace period connector: deliver per-VE proc events under an RCU read lock proc connector: pin task VE for the exit event notification drivers/connector/cn_proc.c | 105 ++++++++++++++++++++++++++++++++++-------- drivers/connector/connector.c | 70 ++++++++++++++++++++++------ include/linux/cn_proc.h | 8 +++- include/linux/ve.h | 2 +- kernel/exit.c | 5 +- 5 files changed, 153 insertions(+), 37 deletions(-) --- base-commit: 1e648e17487b16486de22cefcd27672a454a1c3e change-id: 20260813-connectors-3571be4ae57b -- Best regards, Vasileios Almpanis Software Developer, Virtuozzo.